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ABSTP  ACT 


The  increased  administrative  burden  being  placed  upon 
the  Fleet  increasingly  affects  ship  performance  and 
personnel  morale  and  retention.  Ihe  Shipboard  Non-tactical 
ADP  Program  (SNAP)  is  being  instituted  in  order  to  alleviate 
these  burdens.  However,  the  "applications  approach"  being 
used  with  SNAP  is  not  sufficient  to  meet  both  the  functional 
a£d  management  needs  of  the  Fleet.  The  management  environ¬ 
ment  necessary  to  satisfy  both  of  these  needs  are  discussed. 
The  central  theme  is  than  of  neutralization  and  standardiza¬ 
tion  of  data,  its  definition,  aid  its  control.  Fundamental 
to  the  above  philosophy  is  the  roncept  of  Information 
Resource  Management  (IRK).  Automation  of  IBM  should  be  dons 
via  a  Data  Base  Management  System  (DBMS).  The  critical  tool 
required  to  transfer  CRM  results  to  a  DBMS  is  the  Data 
Dictionary  System  (DD5) .  Additionally,  two  crucial  manage¬ 
ment  positions,  the  IPM  manager  ar.d  the  Data  Base  Admin¬ 
istrator  (DBA)  ,  are  essential  to  the  success  of  this  "data 
base  approach." 
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I.  INTRODUCTION 


A.  BACKGROUND 

The  shipboard  non- tactical  automated  data  processing 
(&DP)  program  (SNAP)  /as  initiated  in  response  to  CNO  objec¬ 
tive  No.  5,  which  required  the  alleviation  of  the  adminis¬ 
trative  burden  or.  the  Fleet.  Tie  constantly  increasing  rate 
of  peace-time  administrative  requirements,  coupled  with  the 
reduction  of  shi;  oari  manning  levels,  has  significantly 
reduced  Fleet  effectiveness  by  increasing  the  administrative 
burden  on  the  Fleet  to  an  unmanageable  level.  Although  many 
ships  and  shore  installations  use  computers  to  fulfill 
administrative  needs,  the  administrative  burden  is  still 
present  because  the  computers  have  been  around  since  the 
mid-1960's  and  their  operation  is  very  machine  dependent. 
Additionally,  the  smaller  operating  units  of  the  Fleet  are 
still  trying  to  accomplish  the  excessive  administrative 
requirements  manually.  Thus,  tiers  is  a  need  to  insure 
"(1)  data/information  is  collected  only  once  at  the  ship¬ 
board  level  and  maintained  and  utilized  for  shipboard 
functions;  (2)  minimum  upline  reporting  with  shorebased 
initiated  automated  reconciliation  of  shipboard  data/ 
information;  and  (3)  maximum  automated  interface  with  other 
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Fleet  or  shore  supporting  automated  information  systems.  An 
automated  support  capability  that  will  assist  shipboard 
personnel  with  their  support  functions  and  inherently 
provide  for  minimum,  accurate,  and  timely  data  information 
update  and  exchange,  will  result  in  improvad  Fleet  readi¬ 
ness,  enhanced  capability  to  meet  all  operational  require¬ 
ments  and  improved  personnel  morale  and  retention.”  [1:  2-u  ] 

Officially,  SNAP  is  "the  automation  of  non-tacti cai 
requirements  of  Fleet  operational  and  direct  support  units, 
afloat  and  ashore,  which  will  employ  uniform  fleet  non- 
tactical  Automated  Data  Processing  Equipment  (ADPE).” 

[Is  2-2]  SNAP  I  and  SNAP  II  are  the  two  subordinate 
projects  underway  to  accomplish  GNO  objective  No.  5.  Both 
projects  address  the  same  areas:  supply/fiscal,  maintenance, 
and  personnel.  However,  the  main  thrust  of  SNAP  I  is  to 
replace  the  AN/UYK-5(7)  computer  which  has  been  supplying 
Fleet  non-tactical  A3?  since  the  mid-1960's  for  larger  ships 
(e.g.,  CV,  LHA)  ,  Marine  Air  Groups  (MAGs),  and  shore  activi¬ 
ties.  SNAP  II,  on  the  other  hand,  is  aimed  at  automating 
supply,  maintenance,  and  personae!  functions  for  smaller 
ships  (e.g.,  FF,  DD,  GG)  ,  which  are  presently  performing 
these  functions  manually.  Both  projects  are  being  developed 
under  separate  contracts  (Honeywell  for  SNAP  I;  Harris  for 
SNAP  II)  ,  but  both  systems  will  be  able  to  interface  with 
each  other.  Physical  implementation  will  begin  during  the 
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1983/1934  t  iae  frame;  ar.d  after  complete  implementation 
thousands  of  processors  and  teas  of  thousands  of  CRT  termi¬ 
nals  and  printers  will  have  beea  installed  at  both  shore  and 
afloat  commands  for  both  the  Navy  and  the  Marine  Corps  at  a 
cost  in  excess  of  one  billion  dollars. 

B.  SNAP  IS  USING  AN  APPLICATIONS  APPROACH 

The  development  of  a  computer  system  can  be  viewed  as 
following  one  of  two  approaches:  an  applications  approach  or 
a  data  base  approach.  [2]  Under  the  applications  approach 
computers  are  thought  to  be  electronic  filing  systems  which 
are  designed  to  satisfy  specific  output  requirements  based 
on  a  set  of  pre-detecmined  nsals.  The  initial  intention  of 
the  the*  data  processing  department  in  this  environment  is  to 
develop  the  various  computer  applications  required  to 
fulfill  the  pre-detecmined  needs.  Once  the  applications  are 
developed  the  function  of  the  data  processing  department 
will  be  that  of  maintenance  of  the  different  applications. 

The  filing  systems  and  the  associated  applications  are 
developed  for  individual  managers  and  departments.  However 
the  independent  filing  systems  and  application  programs  will 
have  to  be  integrated  because  their  dependencies  upon  each 
other  are  necessary  for  th'  attainm>  nt.  of  the  overall  objec¬ 
tives  and  goals  of  tha  orgar' .att^a.  This  integration  is 
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predictable  because  the  organization's  performance  is 
dependent  upon  effective  inter-relationships  among  the 
subordinate  managers  and  departnents.  Thus,  a  two-fold 
problem  will  develop  from  this  approach:  (1)  the  necessity 
of  integrating  decentralized  files  and  programs  which  are 
developed  independently  by  different  personnel;  and  (2)  the 
integration  effort  will  inevitably  fall  upon  the  data 
processing  department  whose  function  is  basically  the  main¬ 
tenance  of  the  fij.es  and  programs,  noi  the  r  crmuxa  ^ror  or 
policy,  creation  of  standards,  and  resolution  of  inter¬ 
departmental  conflicts. 

Appleton  refers  to  this  type  of  data  processing  environ¬ 
ment  where  computers  are  used  as  electronic  filing  systems 
which  raceive,  store,  process,  and  report  as  the  "applica¬ 
tion  systems  syndrome.  This  " sy sn drome"  is  characterized  by 
a  set  of  assumptions  made  by  management:  ]  2:  86] 

•  Systems  will  be  bailt  for  individual  managers,  not 
the  company  as  a  whole. 

•  Data  processing  input,  storage,  and  processing  tech¬ 
niques  will  be  geared  to  specific  output  needs. 

•  The  data  processing  environaent  will  serve  managers 
who  want  computers;  i.  e.,  it  will  evolve  along  the 
"path  of  least  resistance." 

•  Investments  for  computer  hardware,  software,  and 
personnel  will  be  based  on  current  demand  for 
computer  applications  and  will  be  increased  as  that 
demand  increases. 

•  Automated  systems  will  work  manually  before  they  can 
be  computerized. 
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•  The  data  processing  departaent  will  hare  no  respon¬ 
sibility  for  system  or  data  integrity  Deyond  wririr.g 
programs  that  work. 

•  Justifications  for  data  processing  services  will  be 
based  on  cost  trade-offs  (most  often  personnel 
reductions),  application  by  application,  rather  rhan 
by  company  plans  to  improve  overall  efficiency  or 
productivity. 

A  review  of  the  mission  Eleaent  Need  Statement  (MENS) 
for  both  SNAP  I  [1]  and  SNAP  II  *3]  (summarized  in  the 
previous  section)  in  context  of  the  above  "symptoms"  of 
"application  systems  syndrome"  indicate  that  an  applications 
approach  is  being  used  with  the  SNAP  program;  i.e.,  a  fixed 
number  of  master  files  wiil  be  developed  to  satisfy  pre¬ 
determined  functions,  thereby  locking  beneficial  data  into 
the  pre-det ermined  applications  for  certain  parts  of  the 
organization  rather  than  making  this  data  accessible  for  the 
benefit  of  the  whole  organization.  At  the  time  of  this 
writing  the  SNAP  administrative  functions  will  be  automated 
by  using  the  file  management  facilities  of  the  computer 
operating  system.  FiLe  manipulation  will  require  complete 
applications  programs;  no  ad  hoc  query  capability  will  be 
implemented.  Also,  general  updating  of  files  will  be 
performed  by  batched  transactions. 

The  MENS  for  SNAP  I  alludes  to  a  more  sophisticated 
approach  to  development  of  the  SNAP  computer  systems;  "The 
management  data  needed  is  not  available  in  a  timely  and 
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accurate  manner  to  the  operating  managers.  Etfect_vs 
management  decisions  are  dependant  upon  accurate  and  timely 
management  data.  Such  on-line#  transaction  driven,  query 
interactive  access  to  management  data  is  not  achievab^=  as 
long  as  the  status  quo  is  maintained  and  cost-effective 
automated  support  is  not  provided.''  [1:  2-5]  However,  the 
more  rudimentary  applications  approach  is  presently  being 


used  because  it  is  felt 


that  the  experience  and  training  of 


shipboard  personnel  is  non  sufficient  to  ma.inca_n  a  c«". 
data  base  (which  is  part  of  the  more  sophisticated  "data 
base  approach"  to  be  addressed  Later)  in  a  reliable 


condition. 


As  indicated  above,  the  decision  to  forego  the  implemen¬ 
tation  of  a  Data  Base  Management  System  (DBMS)  with  SNAP  was 
based  on  technical  lia itatigns. ‘  The  concept  supported  by 
this  paper  is  that  tie  predominant  problems  to  be  addressed 
when  implementing  a  DBMS  aboard  ship  under  SNA?  should  be 
managerial.  This  is  no*  to  say  that  the  problem  of  main¬ 
taining  a  reliable  data  base  is  not  important,  nor  that 
maintaining  a  data  base  is  as  easy  as  maintaining  "flat 
files.”  Maintenance  of  a  reliable  data  base  is  more  complex 


‘Naval  Air  Logistics  Command  Information  System 
(NALCOMIS)  functions  will  be  automated  with  a  data  base 
management  system.  However,  development  is  being  conducted 
under  a  separate  program  from  SNAP  I  and  SNAP  II. 
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thar.  maintaining  "fiat  files,"  and  the  maintenance  of 
reliable  data  in  any  approach  to  the  development  of  a 
computer  system  is  a  significant  consideration  prior  to 
implementation.  However,  overcoming  technical,  "cockpit" 
problems  is  relatively  easier  tian  the  more  abstract  manage¬ 
rial  problems  that  arise  with  computer  systems  development. 

C.  THE  DATA  BASE  APPROACH 

Since  the  operational  and  organizational  environment  of 
an  organization  constantly  undergoes  change,  it  stands  to 
reason  that  information  requirements  of  new  operational 
procedures  and  new  organizations  are  also  dynamic.  The 
applications  approach  basically  supports  static,  routine 
information  requirements.  Thus,  the  limited  ability  to 
satisfy  only  specific  functional  needs  does  not  account  for 
changes  to  the  management  decision-making  process. 

Therefore,  a  more  versatile  alternative  to  the  applications 
approach  is  needed  in  order  for  computer  automation  to 
control  the  ability  to  respond  efficiently  and  effectively 
to  changing  information  needs.  This  more  viable  alternative 
is  the  data  base  approach. 

A  simplified  explanation  of  the  data  base  approach  is 
that  it  entails  the  development  of  "an  automated  pool  of 
accurate  and  timely  data  which  could  be  easily  and  equally 
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the  inf orma tion 


drawn  upon  to  satisfy,  on  demand, 
requirements  of  management's  decision  problems. ’•  [2:  35  ] 

The  data  base  approan  encompasses  three  types  of  data 
bases:  (1)  two  or  thrae  cantral  dara  basf  -  that  contain  much 
of  the  organization’s  data  and  are  commonly  used:  (2) 
several  functional  data  bases  that  each  contain  data  shared 
by  a  more  limited  set  of  prograis;  and  (3)  a  small  number  of 
dedicated  data  bases  that  accomodate  single  applications. 

[4:  3]  In  order  to  implement  tiese  data  bases,  rather  than 
developing  input,  storage,  processing,  and  output  techniques 
to  satisfy  specific  pre-deteraiaed  reguireaents  (as  does  the 
applications  approacai  ,  the  data  base  approach  consists  of 
three  basic  control  systems:  (1i  a  data  base  input  control 
system,  (2)  a  data  base  output  control  system,  and  (3)  a 
data  base  storage  and  processing  system.  *2:  67]  These 
gcntrgl  systems  differ  from  the  fili^2  systems  of  the  appli¬ 
cations  approach  in  chat  they  are  essentially  standardized 
for  use  by  the  entire  organization  rather  than  individually 
developed  for  each  separate  application. 

The  basic  functions  of  the  input  control  system  (input 
techniques,  edits,  audits,  security,  and  diagnostic 
controls)  are  intended  to  optimize  data  quality,  integrity, 
and  cost.  Data  is  captured  at  its  source  with  no  regard  as 
to  its  intended  use.  once  established,  the  input  control 
system  will  not  significantly  change  because  it  is  not 
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subordinate  to  the  company  structure  or  to  individual 
management  prerogatives.  The  input  control  system  would 
undergo  change  only  i£  more  or  less  data  of  higher  or  lower 
quality  were  required,  or  if  technological  advances  made 
data  input  more  efficient  or  cost  effective. 

Unlike  the  input  control  system,  the  output  control 
system  is  subordinate  to  both  company  organization  structure 
ar.d  specific  management  prerogatives.  These  dependencies 
enable  a  wide  range  of  management  decision-making  needs  to 
be  fulfilled.  Thus,  output  control  systems  are  developed  to 
support  the  dynamic  world  of  output  demand.  Changes  to  the 
output  control  system  are  initiated  by  almost  anything,  such 
as  personalities,  management  styles,  economics,  politics, 
changes  in  functional  responsibilities,  etc. 

The  storage  and  processing  control  system  manages  the 
data  itself,  receiving  data  from  the  input  control  system 
and  passing  it,  on  demand,  to  the  output  control  system. 

The  storage  and  processing  control  system  controls  the  data 
base's  physical  structure,  whicn  is  dynamic  in  nature 
because  physical  organization  of  the  data  depends  on  the 
different  logical  views  of  the  data  held  by  the  users. 

Thus,  changes  to  the  system  are  made  to  optimize  efficiency 
and  cost  effectiveness.  The  processing  and  control  system 
is  generally  implemented  with  a  data  base  management  system 
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that  has  built -hr.  capabilities  to  control  backup  and 
recovery,  data  availability,  security  ar.d  privacy,  computer 
effiency,  etc.  Each  occucanca  bf  a  new  application  there¬ 
fore  does  not  need  to  develop  taase  functions  independently. 


The  successful  imp lementatioa  of  a  data  base  environment 
requires  da  velopmei  t  within  tha  following  guidelines: 
f  2:  92] 

•  The  data  base  must  be  built  for  the  whole  company, 
not  for  individual  managers. 

•  Data  base  development  must  follow  a  logical,  well 
orchestrated  plan,  not  tha  path  of  least  resistance 
(i.e.,  use  of  the  computer  by  only  those  managers 
who  want  to  use  it )  . 

•  Data  processing  mast  be  intended  to  improve  overall 
productivity  by  supplying  accurate  information  based 
on  management  needs,  not  justified  through  cost 
reductions  based  on  personnel  placement. 

•  Management  must  concentrate  primarily  on  identifying 
the  information  it  needs  to  manage. 

•  A  single  entity  must  control  what  is  stored  on  the 
computer  and  how. 

•  Company  input  responsibilities  should  be  established 
and  funded  separately  from  output  needs. 

•  The  single  entity  in  control  of  the  data  base  must 
be  given  increased  responsibility  for  input  control 
and  data  integrity  and  accordingly,  authority  for 
defining  and  obtaining  required  input. 

•  Investments  in  hardware,  software,  and  personnel 
must  be  based  on  the  needs  of  the  data  base  control 
systems,  not  on  requirements  for  specific  applica¬ 
tions. 
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D.  THESIS  PURPOSE  AND  ORGANIZATION 

This  paper  is  written  on  the  premise  that,  given  use  of 
the  applications  approach  to  iata  base  development,  ship¬ 
board  use  of  non-tactlcal  ADP  will  follow  the  traditional 
computer  system  development  cycle  illustrated  in  Figure  1  as 
user  knowledge  and  experience  increases  with  exposure  to  the 
ADP  environment.2  Note  that  the  initial  stages  of  develop¬ 
ment  employ  an  applications  approach,  whereas  the  latter 
stages  use  the  data  base  approach.  However,  because  the 
applications  approach  and  the  data  base  approach  support 
independent  philosophies,  the  initial  use  of  an  applications 
approach  is  not  a  pre-requisite  for  the  data  base  approach. 
In  fact,  the  transition  from  an  applications  approach  to  a 
data  base  approach  will  prove  costly  and  disruptive  to  an 
organization.  Additionally,  the  global  characteristics  of 
the  data  base  approach  result  in  a  more  "user  friendly" 
environment  that  expands  the  objectives  of  the  applications 
approach  to  an  organization-wide  basis.  Therefore,  the 
purpose  of  this  paper  is  to  explain  that  a  data  base 
approach  to  SNAP  system  developaent  is  a  more  effective 
response  to  CNO  Objective  No.  5,  and  to  outline  the 


2The  S-shaped  curve  in  Figure  1  represents  ADP  expendi¬ 
tures.  This  continual  increase  in  capital  outlay  for 
computer  systems  illustrate  the  increased  importance  of 
information  processing  to  organizational  management. 
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managerial  framework  in  which  a  data  base  approach  shoal  i  be 
conducted. 

The  fundamental  managerial  concept  underlying  the  data 
base  approach  is  that  data  (and  the  information  generated 
from  data)  is  an  organizational  resource,  and  is  net  part  of 
particular  applications  system  indar  the  cognizance  of  indi¬ 
vidual  line  managers.  This  concept  of  Information  Resource 
Management  (IBM)  ,  and  the  "IRS  executive"  who  coordinates 
the  selection  and  placement  of  data  in  the  organizational 
data  bases,  is  discussed  in  Chapter  II. 

In  order  to  effectively  support  automation  within  the 
data  base  approach,  most  of  the  organizational  data  will 
have  to  be  centralized.  4 it h  data  centralization,  data  is 
r.o  longer  owned  by  individual  managers.  Instead,  individual 
interests  become  subordinate  to  to  the  organization  as  a 
wheie,  and  managers  will  become  more  dependent  upon  their 
peers  and  other  departments.  lie  primary  tool  to  define, 
catalogue,  and  identify  relationships  in  the  centralized 
data  is  the  Data  Directory  System  (DDS)  ,  addressed  in 
Chapter  III. 

The  IRM  concept  establishes  da ta/inf creation  as  an 
organizational  resource.  The  DDS  is  the  primary  tool  in 
controlling  this  resource.  However,  "some  sort  of  informa¬ 
tion  system  is  needed.  That  class  of  systems  have  come  to 
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be  known  as  data  bass  management  systems."  [6:  ID/21]  Data 
Base  Management  Systems  (DBMSs)  are  more  compatible  with  I3M 
and  DDS.than  traditional  file  management  systems  used  in  the 
applications  approach  because  a  DBMS  is  designed  to  enable 
centralized  files  of  data  to  be  shared  by  various  users. 

The  advantages  of  DBMSs  over  applications  systems  is 
discussed  in  Chapter  CV. 

Finally,  under  the  data  base  approach*  the  ISM  executive 
deals  with  upper  level  management  of  data  and  information 
necessary  to  fulfill  organizational  goals  and  objectives. 
However,  an  additional  manager  is  also  needed  to  be  the 
custodian  of  the  physical  data  base  resulting  from  the 
efforts  of  the  IRM  executive.  this  person  is  the  creator 
and  enforcer  of  standards  and  policies  relating  to  the  use 
of  the  DBMS,  DDS,  and  other  computer-related  equipment. 

These  duties  constitute  the  Data  3ase  Administrator  (DBA) 
function,  and  are  addressed  in  Chapter  V. 


2D 


II 


I^FOa MAT! ON  RES30RCE  MANAGEMENT 


The  nain  functions  of  the  Combat  Information  Center 
(CIC)  aboard  ship  are  the  collection,  processing,  display, 
evaluation,  and  dissemination  of  information.  Standard, 
Navy-wide  procedures  for  executing  these  functions  are  found 
in  a  multitude  of  directives  and  publications.  Through  this 
documentation,  a  methodology  is  established  whereby  masses 
of  input  data  are  converted  to  relevant  information  that  is 
necessary  for  the  ship  to  carry  out  its  assigned  mission. 
This  standardization  of  information  handling  results  in 
information  flows  which  are  understood  by  al^  personnel 
because  the  effectiveness  of  the  ship  as  a  whole  is  being 
enhanced.  A  similar  situation  cm  be  seen  with  the  ship's 
Damage  Control  (DC)  procedures. 

The  urgency  of  quick,  and  correct,  actions  required  of  a 
ship  in  various  combat  and  non-combat  situations  is  the 
impetus  for  establishing  concrete  information  policies 
referred  to  above,  dandling  of  information  in  this  manner 
exemplifies  the  concept  of  Information  Resource  Management 
(IBM).  With  the  implementation  of  SNAP,  the  capability  will 
exist  to  extend  this  I RM  concept  to  the  "total  ship." 
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Strict  guidelines  for  inf orn atior.  handling  have  to  oe 
developed  just  as  for  the  more  tangible  resources  of  money, 
people,  and  material  because  the  fast-paced,  dynamic  envi¬ 
ronment  characterized  by  complex  technological  advances  have 
created  what  Forest  4.  Horton,  Jr.  terms  an  "information 
explosion."  [7:  1]  3n  the  other  hand,  "the  demand  for  data, 
like  the  demand  for  dollars,  or  people,  or  supplies,  or 
office  space,  tends  to  exceed  supply."  [7:  22]  How  then  can 
the  “information  explosion"  be  a  problem  when  theoretically 
the  demand  for  this  information  exceeds  the  supply?  The 
answer  lies  in  the  effect  that  Information  has  on  an  organi¬ 
zation  or  manager.  The  greater  the  quantity  of  relevant 
information  that  an  organization  or  manager  can  acquire,  the 
better  the  chance  that  uncertainty  surrounding  the  organiza¬ 
tion  or  manager  is  reduced.  Since  total  certainty  is  gener¬ 
ally  regarded  as  impossible,  the  demand  for  information 
needed  to  reduce  existing  uncertainty  will  always  exceed 
what  is  available.  lowever,  reLevant  information  is  lost  in 
a  forest  of  irrelevant  or  marginally  useful  information; 
i.e.,  "the  glut  of  marginally  reLevant  information  is  clog¬ 
ging  our  communications  channels  and  thereby  preventing 
useful  information  from  reaching  our  decision-makers. ...  it 
is  (therefore)  necessary  to  maximize  the  effectiveness  and 
efficiency  dealing  with  the  use  of  the  information 
resource.”  [7;  2,  22] 
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The  development  of  SNAP  can  be  considered  a  significant 
indicator  that  the  marginal  information  handling  capabili¬ 
ties  in  the  Navy  are  affecting  its  performance  to  a  high 
degree.  Therefore,  information  should  be  aanagei  in  the 
context  of  a  resource  management  discipline  wherein 
"a  resource  can  be  thought  of  as  something  observable  which 
can  be  categorized.  &  resource  is  something  usable,  nor 
only  for  its  original  purpose,  but  extending  to  a  purpose 
beyond  the  original  one.  Finally,  a  resource  to  be  managed 
must  be  collectable  and  not  dispersed  within  the  organiza¬ 
tion.  Management  of  a  resource  means  that  opportunities 
exist  to  conserve  the  resource,  to  attend  to  the  efficiency 
and  effectiveness  of  use  of  the  resource  and  to  iook  for  a 
payoff  in  the  profits  of  the  organization  through  the  effec¬ 
tive  utilization  of  the  resource  itself."  ‘3:  ]  Using 

this  frame  of  reference  when  implementing  SNAP  will  enable 
the  benefits  of  automation  to  extend  beyond  the  predeter¬ 
mined  requirements  to  the  arena  of  management  decisions. 

The  initial  step  in  using  the  IFM  concept  is  under¬ 
standing  the  nature  of  information:  "data  can  be  defined  as 
unevaluated  caw  facts,  while  information  may  be  thought  of 
as  evaluated  data,  that  is,  facts  which  have  been  inter¬ 
preted  in  some  manner  so  as  to  give  them  more  value  than 
they  had  in  the  natural  stats."  [7:  2]  7iswed  as  an  organi¬ 
zational  resource,  information  Is  conceptually  similar  to 
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other,  traditional,  resources  (i.e.,  money,  people,  and 
material)  because  it  has  vaiua  (in  terms  of  time,  manpower, 
etc.),  and  it  has  qualities  (e.g.,  time  of  availability, 
accuracy,  method  of  display,  ato.)  which  can  be  controlled. 
[9:  43-44]  additionally ,  managers  continually  find  them¬ 
selves  asking  the  saae  type  of  questions  aoout  information 
as  they  do  about  the  other  organizational  resources:  "What 
information  will  i  need?  When  will  I  need  it?  How  accurate 
must  i*-.  be?  Tr.  what  form  will  it  be  most  useful  to  me?  How 
shall  I  organize  this  information?"  [9:  46]  To  answer  these 
questions,  management  of  the  information  resource  must  be 
"concerned  with  the  policies  and  procedures  which  govern  the 
processing  and  movement  of  information  -  such  factors  as  the 
structure  of  the  information,  i:s  content  and  make-up,  its 
completeness  and  authenticity,  its  availability  and  accessi¬ 
bility,  its  timeliness  and  accuracy,  and  so  on."  [10:  7] 
Another  way  to  grasp  the  idea  of  information  as  a  resource 
is  by  using  an  analogy  of  a  mineral  resource  like  coal. 

Coal:  [7;  4  1-4  2] 

•  has  an  acquisition  cost; 

•  comas  in  several  different  grades,  some  harder  and 
more  expensive  to  mine  than  others; 

•  comes  in  various  degrees  of  purity; 

•  must  be  refined  and  processed  to  enhance  its  value; 

•  passes  through  many  hands  from  point  of  acquisition 
to  point  of  use; 
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•  has  many  synthetics  to  compete  with  -  some  cheaper, 
soma  nor?  expansive; 

•  can  be  bought  and  processed  in  its  raw  material  form 
and  thus  integrated  vertically,  or  can  be  bought  in 
more  refined  and  processed  forms;  and 

•  is  subject  to  the  value  aided  principle3  at  each 
stage  in  its  life  cycle;  and  transfer  pricing  prin¬ 
ciples  and  techniques  can  be  applied  as  it  moves 
along  its  path  from  acquisition  to  use. 

The  next  step  is  to  establish  a  management  function 
whose  purpose  is  to  "define,  measure,  package,  manage, 
utilize,  and  dispose  of  that  (information)  resource 
according  to  prescribed  principles  and  practices."  [7;  '4  3] 
Since  I3M  emphasizes  centralized  management  of  information 
to  enhance  the  operations  of  tae  total  organization,  it  is 
evident  that  coordination  across  organizational  lines  is 
required  to  support  the  XRti  effort.  Aboard  Navy  ships,  SNAP 
systems  will  provide  a  common  denominator  among  the  various 
departments  because  tae  computers  will  be  the  central  repo¬ 
sitory  for  machine  readable  data  used  by  each  department. 
However,  the  IRM  concept  concerns  the  information  itself, 
not  the  processing  of  information;  and  since  the  information 


3"The  value  added  concept  of  information  car.  be  under¬ 
stood  by  categorizing  information  into  different  categories; 
1)  information  for  operation,  2l  information  which  enhances 
operation  and  3)  information  for  decision-making.  Basic 
company  information  collected  for  operational  reasons 
achieves  a  value  added  status  when  it  is  also  used  in 
decision-making  processes.  Information  gathered  which 
enhances  operations  can  achieve  more  value  when  further 
processed  and  combined  with  related  information."  [8:  42] 
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needs  will  be  defined  for  the  total  organization,  the 
responsibility  of  IRS  would  have  to  be  not  at  the  Data 
Processing  (DP)  center,  but  rather  at  the  aanagement  level 
above  the  departmental  level,  i. e. ,  the  Executive  Officer. 
With  IRM  responsibilities  at  the  Executive  Officer  level  tw 
important  criteria  are  net.  First,  involvement  and  support 
by  top  management  will  be  continual.  Secondly,  the  respon¬ 
sibilities  of  coordinating  information  flows  an  ensuring 
that  information  policies  truly  benefit  the  whole  organiza¬ 
tion  are  separated  from  the  responsibilities  surrounding  th 
mechanics  of  processing  efficient  and  reliable  data.  The 
Executive  Officer,  as  the  ''boss'1  over  all  departments,  will 
sign  off  on  just  how  information  is  to  be  used  aboard  ship 
(with  the  concurrence  of  the  Commanding  Officer,  of  course) 
The  results  are  that  policies  are  implemented  and  enforced 
by  top  management;  and  that  suggestions,  conflicts,  etc.  ar 
processed  up  the  chain  of  command  rather  than  across  depart 
mental  lines  through  the  DP  center. 

The  third  step  is  to  develop  necessary  policies,  proce¬ 
dures,  and  systems  reguired  to  properly  manage  the  informa¬ 
tion  resource.  These  policies,  procedures,  and  systems 
should  be  published,  disseminated  within  the  organization, 
and  include  at  least  the  following:  [11:  58] 

•  Statement  of  overall  objectives  relating  to  the 

overall  company  objectives  and  goals. 
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Or 


•  Hew  or  g  arizatiot*  l  structure  and  responsibilities 
key  personnel. 

•  Policies  and  procedures  for  monitoring,  controlling, 
coordinating,  and  managing  nf  different  activities. 

•  Mechanism  for  identification  and  impleientation  of 
new  requirements. 

•  Mechanism  for  feeiback  from  the  user  community 
regarding  the  effectiveness  of  different  activities. 

•  Mechanism  for  keeping  executive  management  informed 
about  the  developments  (successes  and  failures)  in 
the  information  processing  and  handling  environment. 

•  Mechanism  for  incorporating  improvements  in  any  or 
all  of  the  above  mentioned  policies  and  procedures 
to  achieve  the  stated  objectives  on  an  on-going 
basis. 

In  summary,  the  IRM  concept  views  information  as  an 
oraanizatio  rai  resource  (along  with  men,  people,  and 
material),  the  value  of  which  lies  in  its  jse  by  management 
to  make  sound  decisions.  The  key  ingredient  to  develop  this 
resource  is  the  ability  of  each  manager  to  determine  the 
relevant  information  needed  to  get  his/her  job  done. 

Through  the  leadership  of  the  IRM  "executive,"  data  "litter" 
will  be  eliminated  aad  the  information  needs  of  the  indi¬ 
vidual  managers  will  be  integrated  to  benefit  not  only  them¬ 
selves  but  also  the  entire  organization:  "IRM  is  another  way 
to  think  systematically  about  the  organization  and  its 
objectives.  IRM  seeks  to  identify  the  common  patterns  of 
information  that  exist  in  the  organization,  to  integrate 
these  varied  patterns  across  the  total  organization  into  a 
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coherent  whole,  and  to  provide  guidance  in  the  form  ?f 
standards  ar.d  conventions  to  mats  the  best  use  of  inforaa 
tion  owned  by  the  organization.'*  [9:  46] 


28 


Ill 


IJE  DA JA  DIDTI0NA3Y  SYSTEM 


A.  DESCRIPTION 

The  essential  nana gement  tool  compatible  with  the  IRM 
concept  is  the  Data  Dictionary  System  (DDS).4  A  DDS  can  be 
considered  a  "repository  of  information  about  the  defini¬ 
tion,  structure,  and  usage  of  lira.  It  does  not  contain  the 
actual  data  itself.  ...  the  data  dictionary  contains  the  name 
of  each  data  type  (element),  its  definition  (size  and  type), 
where  and  hew  it’s  used,  and  its  relationship  to  other 
data."  [12:  129]  This  "data  about  data"  contained  in  a  DDS 
is  termed  "meta  data."  By  automating  the  management  of 
definitions  on  which  systems  are  built,  optimization  of  data 
standardization  and  control  can  be  realized,  resulting  in 
improved  DP  productivity  and  system  reliability. 
Additionally,  headaches  associated  with  traditional  documen¬ 
tation  strategies,  and  which  plague  both  an  applications 
environment  and  a  data  base  environment,  can  be  cured.  The 
problems  with  traditional  documentation  strategies  can  be 
summarized  as  follows:  [13:  37] 

♦Within  the  context  of  this  paper,  a  DDS  also  includes 
those  systems  termed  D ictionary/Directory  (D/D),  Data 
Dictionary/Directory  ( DD/D)  ,  and  Data  Element  Dictionary 
(DED)  . 


29 


•  Mer.aoe  a  «nt  of  3ocu ment ation  is  largely  a  manual 
process  which  is  separated  from  events  or  changes 
occurring  within  the  source  or  object  code  of  the 
applications  systems  it  describes. 

•  There  is  no  automatic  guarantee  that  existing  docu¬ 
mentation  is  up-to-date,  synchronized  with  executing 
system  configurations,  or  accurate  in  representing 
the  data  and  system  resources  of  the  (organization). 

•  Managing  and  motivating  the  pursuit  of  comprehensive 
documentation  is  a  difficult  and  time-consuming 
affair . 

•  For  a  number  of  reasons,  the  resulting  material  may 
be  difficult  to  i  =  e  or  ineffective  in  meeting  the 
dynamic  needs  of  the  (organization).  Real  questions 
arise  about  the  authenticity  of  the  information  it 
contain  s. 


A  DDS  espouses  centralization  and  standardization  of 
data.  Therefore,  it  ties  in  closely  with  IRM  (Chapter  I ) 
and  DBMS  (discussed  in  the  next  chapter).  However,  a  DDS  is 
also  well-suited  for  in  applications  environment.  Problems 
with  an  applications  approach  (e.g.,  data  redundancy , 
unchangeability,  inflexibility,  etc.5)  stem  from  decentral¬ 
ized  ownership  and  control  of  data  and  applications  proc- 
cessing.  However,  a  DDS  deals  with  data  definitions,  not 
data  or  applications.  Therefore,  a  DDS’s  centralized  data 
management  approach  to  data  definitions  will  help  alleviate 
these  problems  of  the  applications  approach  by  aiding  "in 
the  collection,  standardization,  an  dissemination  of 


sThe  disadvantages  of  an  applications  approach  are 
discussed  in  more  detail  in  in  Chapter  IV. 
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information  relative  to  the  different  applications  system. 
The  use  of  a  DDS  will  help  enforce  the  development  standards 
concerning  data  item  naming,  usage,  and  coding. ...  The  infor¬ 
mation  contained  within  a  data  dictionary  may  be  used  by 
almost  everyone  connected  with  a  software  system.  A  person 
can  locate  information  needed  to  learn  about  a  system,  a 
component  of  the  system,  or  a  particular  data  item  within  a 
system."  "14:  3  ] 

Meta  data  is  physically  stored  in  a  data  base.  A  DOS 
can  be  cosidered  to  consist  of  two  parts:  a  dictionary  ana  a 
directory.  The  dictionary  comprises  those  data  definitions 
generated  from  the  meta  data,  and  which  are  applied  to 
various  applications.  The  directory  permits  applications  to 
access  the  stored  meta  data  without  requiring  knowledge  of 
their  physical  locations  or  characteristics.  Thus,  the 
directory  is  used  to  enhance  the  versatility  of  the 
dictionary,  enabling  the  DDS  to  perform  the  following 
functions:  [14;  3-4] 

•  Record  keeping.  The  (DDSI  will  document  all  of  the 
data  items  in  one  or  more  applications  systems.  An 
objective  of  the  documentation  is  to  determine 
common  data  elements  and  reduce  redundancy  of  data 
within  the  application  system.  Additionally,  this 
record  keeping  wiLl  aid  in  system  enhancement  and 
correction,  as  well  as  system  documentation. 

•  epos?  Reference.  The  (DDS)  will  maintain  a  useful 
cross-reference  between  the  entities  contained  in 
it.  A  cross-reference  will  be  kept  between  data 
elements,  synonyms  of  elements,  programs,  reports, 
files,  records,  and  users. 
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•  Indexin a.  Indexing  provides  a  means  to  relate  words 
to  their  definitions.  Insy  ran  either  oe  indexed  by 
key  words  (e.g.  ,  a  KWIC  Index)  or  by  standardized 
indexing  terms  (e.g.,  a  KttOZ  Index). 

•  Standar  di^ ation  and  Control.  The  DBA  (Data  3ase 
Administrator)  can  exercise  management  control  over 
all  the  data  eleients  in  the  related  application 
systems.  For  exaiple,  the  DBA  car.  institute  a 
procedure  to  review  all  data  items  for  redundancy 
and  conformance  to  standards  prior  to  their 
implementation  in  the  application  systems. 


A  DDS,  by  its  ability  to  perform  the  above  functions  on 
the  meta  data,  can  produce  a  reliable  dictionary  that  is 
capable  of  answering  questions  posed  by  the  IRJl  manager  such 
as:  [12:  12  9] 

•  What  kind  of  validity  tests  have  been  applied  to 
this  data  type? 

•  who  is  authorized  tc  up  ate  it? 

•  What  modules,  programs,  and  systems  use  this  data 
type? 

•  What  are  the  valid  ranges  of  values  for  this  data? 

•  What  security  level  is  applied? 

•  Who  is  allowed  to  access  the  data? 

•  By  what  other  names  is  the  data  type  known  in 
various  applications  environments? 

•  In  what  reports  does  this  data  type  appear? 

•  What  is  the  input  source  for  this  data  type? 


In  order  to  answer  the  above  questions,  a  DDS  aims  at 

three  objectives:  [  15:  283  ] 

•  In v?fif 2 bY  ana o sb e nt.  The  (DDS)  provides  an  inven¬ 
tory  of  the  data  that  comprise  the  resource  and  of 
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-he  programs,  transactions,  and  screens  used  to 
access  the  source.  The  inventory  includes  names, 
definitions,  locations,  storage  formats,  sizes,  and 
other  characteristics.  With  this  repository  of 
information,  standards  for  names,  access,  storage, 
security,  and  validation  can  be  implemented  and 
enforced  more  easily. 

•  Cost  Z or.trol.  A  (DDS)  helps  to  control  the  costs  of 
developing  and  maintaining  computer-based  applica¬ 
tions.  A  (DDS)  can  provide  an  accurate  and  complete 
library  of  data  definitions  for  use  both  in  applica¬ 
tion  programs  and  in  canned  program  generators  such 
as  report  writers  and  query  processors.  Maintenance 
efforts  can  also  oe  facilitated  through  use  of 
reports  generated  by  the  (DOS)  that  help  to  predic- 
the  effects  of  change  in  one  part  of  an  information 
system  on  other  parts  of  the  system. 

•  Resilie  ncy .  A  DDS  improves  the  resiliency  of  the 
data  resource  to  changes  in  the  data  processing 
environment.  Achievement  of  data  independence  from 
the  characteristics  of  a  particular  hardware  and 
software  environment  allows  the  information  resource 
to  adapt  to  changing  raguire meats. 


B.  CLASSIFICATION 

A  DDS  may  be  classified  la  one  of  tvc  ways.  One  classi 
fic&tion  is  by  the  capability  oE  the  DDS  to  provide  data 
entry  descriptions  to  other  software.  In  this  context,  the 
DDS  can  be  said  to  be  passive  or  active.  »ith  a  passive 
DDS,  the  data  entry  descriptions  will  exist  within  the  DDS 
and  other  software  (i.e.,  COBDL  programs)  on  an  independent 
basis.  Therefore,  changes  in  tie  DDS  do  not  automatically 
result  in  corresponding  changes  in  the  software  containing 
the  appropriate  entity  descriptions,  and  execution  of  appli 
cations  programs  do  not  include  automatic  checking  with  the 
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DDS  for  correctness  of  data  definitions,  Thus,  the  DD3  in 
itself  doss  not  control  definitions  of  the  organization's 
data.  It  rather  wouLi  be  the  primary  reference  used  to 
control  the  definitions  manually,  f  1 6 :  6-7] 

On  the  other  hand,  an  active  DDS  is  the  only  source  for 
data  descriptions  used  in  other  processing  components  such 
as  compilers,  assemblers,  and  D3NSs.  Enforcement  of  data 
standards  and  usage  throughout  ;he  organization' s  aoolioa- 
tions,  and  changes  to  appropriate  software  using  data 
descriptions  that  are  changed  ia  the  DDS,  are  accomplished 
automatical ly  by  the  DDS  instead  of  manually.  As  an 
example,  an  active  DDS,  using  dictionary  information  and 
parameters  supplied  in  the  jon  stream,  could  produce  the 
DATA  DIVISION  for  any  COBDL  program  without  manual  interven¬ 
tion.  r he  portion  of  the  program  produced  by  the  DDS  will 
be  interspersed  with  the  rest  of  the  source  program  when  the 
program  is  compiled.  Additionally,  if  the  DATA  DIVISION  was 
produced  manually,  it  would  be  automatically  verified  by  the 
DDS  before  program  execution.  [15:  7] 

The  second  classification  of  a  DDS  is  according  to  its 
dependence  on  other  software  for  implementing  its  functions. 
In  this  respect,  the  DDS  may  be  termed  stand-alone  or  depen¬ 
dent.  A  stand-alone  DDS  is  self-contained.  Its  functions 
are  performed  without  relying  oi  any  other  general  purpose 
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software  such  as  a  DBMS.  k  stand-alone  DD3  may  be  active  cr 
passive.  [16:  6 ,  7  ] 

A  DDS  that  is  designed  to  operate  in  conjunction  with 
another  general  purpose  software  system  such  as  a  DBMS  is  a 
dependent  DDS.  This  type  of  DD3  requires  the  facilities  of 
the  general  purpose  software  system  (e.g.,  DBMS)  in  order  to 
perform  DDS  functions.  [15:  7]  Phis  type  of  DDS  can  be  said 
tc  be  an  "in-line"  DD3 ,  and  in  is  generally  used  with  a 
DBMS.  Essentially,  this  in-line  DDS  is  an  elaboration  of  an 
active  DDS  in  that  the  D3MS  directory  serves  as  the  direc¬ 
tory  for  both  the  DDS  (for  data  definitions)  and  the  DBMS 
(for  the  object  data  requested  oy  the  user  application). 

[13:  42] 

C.  SUMMARY  OF  BENEFITS. 

In  summary,  a  DDS  can  be  considered  "a  single,  authori¬ 
tative  source  of  information  on  data  elements,  their  use, 
and  their  organization  and  format.  It  is  a  way  of  moni- 
torina  and  controlling  data  resources  without  actually  inte¬ 
grating  and  centralizing  the  data  itself.  Instead, 
information  on  data  is  integrated  and  centralized  in  a 
single  file."  [17:  32]  The  centralization  and  standardiza¬ 
tion  themes  of  a  DDS  makes  it  very  comparable  with  IRM  as 
well  as  providing  the  following  benefits:  [16:  8] 
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•  Becter  centre!  of  the  organizations ' 
through  improved  (i.e. ,  centralized, 
standardized)  data  definitions,  data 
data  collection  procedures. 

•  Improved  transportability  of  data  and  software 
between  computing  environments  through  standardized 
data  and  data  definitions. 

•  Improved  documentation  for  data  bases,  programs  and 
systems . 

•  Automatic  compilation  of  data  definitions  to  be 
included  in  application  programs  or  in  DBMS  data 
base  definitions. 

•  Increased  security  and  access  control  for  the  data 
base  environment. 

•  Effective  aid  to  software  development,  modi f ication, 
and  maintenance  through  configuration  management  of 
system  components  of  data  aid  programs. 

•  Increased  cost-effective  use  of  resources  throughout 
the  system  development  life  cycle. 


The  benefits  of  a  DDS  dir eel y  impact  six  major  user 
groups:  [  15:  289  ] 

•  Data  administrators,  who  use  the  system  as  a  major 
tool  for  inventorying  the  data  resource,  imple¬ 
menting  standards,  and  designing,  monitoring,  and 
restructuring  data  bases. 

•  Application  personnel,  who  use  the  system  to  reduce 
program  coding  efforts,  to  store  the  design  of 
evolving  systems  and  to  support  analysis  of  system 
changes . 

•  Operations  staff,-  who  retrieve  information  about 
jobs  from  the  (DD3). 

•  Data  processing  nanagaaent,  who  receive  high-level 
impact  and  summary  reports  about  data  usage  from  the 
(DDS)  . 

•  End-users,  who  obtain  descriptions  of  their  data 
views  from  the  (DDS). 

•  Auditors,  who  examine  and  obtain  data  descriptions 
for  use  in  auditing  software. 


lata  resource? 
rigorous,  and 
handling  and 
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IV 


•  PILE  SANA GEMENI  VS  DATA  3ASE  SAN  AGE  SENT 

A.  PROBLEMS  WITH  TRADITIONAL  FILS  MANAGEMENT 

As  stated  previously  the  traditional  file  management ,  or 
applications  approaca,  is  function-  (i. e. ,  fils)  oriented. 
Data  required  by  a  particular  applications  program  (or  set 
of  applications)  are  organized  in  files  based  or.  the 
requirements  of  the  particular  program  (s).  The  objective  in 
this  organization  is  optimization  of  program  performance 
rather  than  the  information  uss  of  the  data  content  of  the 
files.  Thus,  the  result  of  function-oriented  files  is  the 
limitation  of  data,  vnich  is  probably  common  to  other  appli¬ 
cations,  to  the  realm  of  only  certain  applications.  In 
order  for  files,  containing  data  that  is  collected  for  use 
by  a  particular  application,  to  be  used  by  another  applica¬ 
tion,  it  is  necessary  to  process  the  files  into  a  different 
form  or  format  required  by  the  additional  applications. 

C  18:  1-1] 

The  use  of  a  function-oriented  approach  leads  to  the 
creation  of  several  major  problems.  [19:  9-10]  The  first 
major  problem  is  data  redundancy .  Re-processing  of  data 
leads  to  the  occurance  of  the  same  data  type (s)  in  several 
different  places.  With  the  same  data  being  stored  in 
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multiple  places  the  rnar.ce  far  development  of  ir.corsis- e 
cies  increases,  which  in  tarn  impacts  data  integrity;  i. 
it  is  possible  for  a  data  type  Located  in  several  places  to 
be  in  different  states  of  update  at  the  saae  time.  The 
results  will  be  conflicting  reports  and  loss  of  credibility 
by  users  who  must  use  this  inconsistent  data  to  make  deci¬ 
sions.  Additionally,  redundant  data  takes  up  more  storage 
space  in  the  computer  system. 

The  second  disadvantage  of  traditional  file  management 
surfaces  when  changes  to  a  file  system  have  to  be  made.  If 
the  data  format  in  a  file  must  be  changed  for  some  reason, 
then  all  of  the  applications  programs  which  use  that  file 
must  be  located  and  changed  accordingly.  Conversely,  if  th 
value  of  a  data  type  in  one  fils  is  updated,  then  all  files 
containing  that  data  type  must  be  located  and  updated. 
Similar  location  and  verification  actions  must  also  be 
performed  f  cr  additions  and  deletions  of  data  types. 
Therefore  it  is  quite  possible  that  a  trivial  change  to  one 
area  of  the  system  can  cause  a  chain  reaction  of  changes  in 
other  parts  of  the  system.  These  changes  will  be  costly  in 
terms  of  time  and  personnel.6 


•This  could  be  a  considerable  disadvantage  with  SNAP 
since  one  of  the  program  constraints  is  that  no  additional 
shipboard  personnel  are  to  be  required  to  operate  the 
computer  system. 
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Ths  nex*  -  2^3  is  thr  i  neon  sic.  “  rii~y/  incs'?.  — 

ability  of  data/cutput.  is  tie  data  in  each  functional  are 
is  defined,  different  naming  conventions  may  be  used  (a.g., 
SS AN,  SSN,  SOC-SEC,  etc.  for  social  security  number). 
Inconsistent  naming  conventions  will  tend  to  confuse  users 
who  are  unfamiliar  with  certain  representations  of  a  data 
item.  Since  programmers  maintaining  the  systems  must  also 
deal  with  this  type  of  data,  confusion  could  lead  to  delays 
in  developing  applications  to  fit  new  user  requirements. 
Furthermore,  as  data  between  similar  systems  become  more 
diverse  in  their  definitions  and  representations,  output 
could  become  totally  incompatible.  [14:  2] 

A  fourth  major  roadblock  is  the  inflexibility  of  the 
applications  approach.  A  prevalent  Navy  saying  is  "Stay 
Flexible,"  meaning  that  most  day-to-day  operations  are  char 
acterized  by  unexpected  problems  and  situations  which 
require  immediate  attention.  If  decisions  regarding  these 
unexpected  situations  are  to  be  aided  by  computer  generated 
information  using  traditional  file  management  methods,  the 
user  will  quickly  find  out  that  data  items  cannot  be 
re-grouped  to  fit  an  ad  hoc  request  without  first  composing 
a  complete  applications  program  and/or  a  new  set  of  files. 
Although  the  data  may  exist,  information  cannot  be  provided 
in  a  timely,  efficient  manner  that  can  satisfy  the  user. 
This  situation  can  be  colorfully  described  by  the  adage 
"water  water  everywhere;  but  not  a  drop  to  drink." 
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B. 


DBMS  OVERCOMES  FI L  E-OfilEMTED  LIMITATIONS 


It  can  te  ueducei  from  the  aoove  discussion  that  a 
file-oriented  system  would  be  adequate  under  the  following 
conditions:  [18:  1-3] 

•  Limited  scope  of  management  information  capability 
desired . 

•  High  expectation  that  successful  achievement  of  the 
file  system  will  satisfy  the  needs  cf  the  organiza¬ 
tion  for  a  relatively  long  period  of  time  (5  to  10 
years)  . 

•  Use  of  a  relatively  small  volume  cf  data  with  little 
growth  anticipated. 

•  Expectation  of  little  or  no  need  for  redundancy  in 
the  types  of  data  being  used. 

The  static  environment  depicted  by  the  above  conditions  dees 
net  balance  the  SNA ?  requirements  of  developing  a  computer 
system  to  meet  the  constantly  changing  and  growing 
administrative  requirements  imposed  on  the  Fleet. 

Data  base  management  systems  (DBMSs)  are  more  adequately 
suited  to  meet  the  caallenge  of  the  Navy's  administrative 
requirements  because  a  DBMS  is  data-oriented  rather  than 
function-oriented.  This  enables  the  DBMS  to  integrate  data 
in  a  manner  which  enables  multiple  users  to  view  the  same 
data  in  different  frames  of  reference  without  having  to 
create  dedicated  files  or  applications  programs.  In  other 
words,  "the  data  base  is  designed  for  generality,  for  flexi¬ 
bility,  and  extensibility,  both  in  the  design  cf  the  various 
records  and  in  the  files  that  it  includes.”  [18:  1-2] 


Many  problems  existing  in  the  applications  approach  are 
overcome  by  the  DBMS  r haractaris; i c  of  centralization  of 
data.  First,  centralized  data  eliminates  data  redundancy.7 
With  "harmful"  data  redundancy  eliminated  considerable 
savings  in  storage  space  is  possible.  Cost  savings  are  also 
realized  in  the  updating  or  modifying  of  the  data  base 
because  updates  or  modifications  would  only  have  tc  be  done 
once.  Finally,  data  centralization  results  in  economies  of 
scale: 


•  "One  person  working  full  time  on  data  problems  can 
be  more  efficient  than  twenty  people  working  one- 
twentieth  of  their  time  oa  the  probi-ms."  [21:  4] 


•  The  existence  of  only  one  data  base  processing 
system  interacting  directly  with  the  data  base 
"implies  that  the  logical  and  physical  structure  of 
the  data  base,  backup,  security  (and  privacy),  etc. 
are  under  some  form  of  central  control.  Rather  than 
spreading  money  and  effort  across  multiple  frag¬ 
mented  files,  attention  can  be  focused  or.  the  single 
common  data  base."  [22:  135]  This  means  that  "more 
money  and  analyst  time  can  oe  spent  improving  *he 
data  base  processing  system  than  could  be  spent  cn 
any  single  file  processing  system."  [21:  4] 


A  second  major  benefit  of  a  DBMS  is  the  existence  of 
logical  an 4  physical  data  independence.  Logical  data 


7This  is  not  entirely  true.  James  Martin  states  that 
"in  reality  some  measure  of  redundancy  exists  in  many  data 
bases  in  order  to  give  improved  access  times  or  simpler 
addressing  methods.  Some  recoris  are  duplicated  to  provide 
the  capability  to  recover  from  accidental  loss  of  data. 

There  is  a  tradeoff  between  noaceiundancy  and  other  desir¬ 
able  criteria,  and  so  it  would  be  better  to  use  the  phrase 
'controlled  redundancy'  or  minimal  redundancy,  or  say  that  a 
well-designed  data  base  removes  'harmful'  redundancy." 

[  20  :  23] 
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independence  means  that  "the  overall  logical  structure  of 
the  data  may  be  changed  without  changing  the  application 
programs.  (The  changes  must  not,  of  course,  remove  any  of 
the  data  the  application  programs  use.)"  '2D:  30]  Physical 
data  independence  means  that  "the  physical  layout  and  the 
organization  of  the  data  may  be  changed  without  changing 
either  the  overall  logical  structure  of  the  data  or  the 
applications  programs."  [20:  3D]  The  logical  and  physical 
data  independence  provided  by  a  DEWS  is  necessary  if  the 
organization  is  to  consider  data,  and  the  information 
derived  from  data,  as  resources  (as  supported  by  the  IRK 
concept).  With  logical  and  physical  data  independence  users 
are  allowed  to  create  multiple  logical  views  of  a  single 
representation  of  the  data.  In  the  context  of  IRK,  users 
are  able  to  generate  information  in  a  variety  of  forms  from 
the  same  data.  Thus,  each  user  does  not  have  to  create 
separate  applications  programs  and  corresponding  files 
because  the  DBMS  is  able  to  re-lefine  the  data  structures 
according  to  the  requirements  of  each  application. 
Additionally,  changes  to  the  data  itself  and  to  the  applica¬ 
tions  using  the  data  may  be  accomplished  separately  with  no 
effect  upon  each  other. 

with  users  only  considering  their  own  logical  view  of 
the  data,  they  do  not  have  to  worry  about  the  data’s  phys¬ 
ical  representation,  nor  about  now  subsequent  changes  in  the 
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physical  data  base  will  affect  their  programs, 
complex  data  structures  to  represent  the  different  logical 
views  of  the  users;  but  since  the  users  need  not  worry  about 
these  complex  physical  representations,  navigation  through 
the  data  base  is  easy  (from  the  user/programmer  point  of 
view)  because  it  is  accomplished  by  the  DBMS  and  not  by  the 
program  developed  by  the  user. 

.  Another  significant  benefit  of  the  DBMS  is  its  ad  hoc 
S^fiabiiit^,  which  is  based  on  logical  and  physical 
data  independence  and  the  dynamic  integration  of  data.  By 
use  of  a  high  level  query  language,  unanticipated  requests 
fcr  information  can  be  handled  oy  the  DBMS  without  the  need 
for  programming  because  view  definition  and  navigation 
through  the  data  base  are  accomplished  by  the  DBMS,  not  the 
user.  Therefore,  timely  information  retrieval  or  report 
generation  is  possible  on  an  ad  hoc  basis.  This  quick 
access  to  information  not  only  improves  the  quality  of  a 
manager's  unanticipated  decisions,  but  also  programmer 
productivity  by  keeping  systems  programmers  from  being  inun¬ 
dated  with  requests  for  new  applications  and  modifications 
to  existing  applications. 

It  can  also  be  noted,  in  the  case  of  SSAP,  that  the  use 
of  minicomputers  also  provides  in  inherent  advantage  in  data 
base  processing  because  "since  their  inception  minicomputers 
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have  always  beer,  oriented  to  the  on-line  interactive 
environment*  (and}  data  bass  operations  also  tend  to  be 
oriented  to  the  on-line  interactive  environment.... 
Obviously,  if  the  hardware  architecture  and  the  operating 
software  is  interactive,  then  interactive  data  base  opera¬ 
tions  are  a  natural  function  for  the  minicomputer.  It  can 
be  gerneralized  that  it  is  easier  to  run  batch  operations  on 
an  interactive  system  than  it  is  to  make  a  batch  system  run 
interactive  applications."  [23:  SP/26  ] 

In  summary,  the  user-oriented  data  approach  of  a  DBMS 
yields  advantages  to  management  in  the  need  for  fewer 
personnel;  and  in  faster,  more  improved  responses  to  infor¬ 
mation  requirements,  especially  those  that  are  unantici¬ 
pated.  Finally,  few  information  systems  used  in  executive 
decision-making  are  immune  from  new  and  changing  require¬ 
ments.  &  DBMS  provides  the  flexibility  to  respond  to 
changes  in  a  timely  fashion  by  separating  the  user  from  the 
data  and  by  enabling  a  variety  of  data  relationships  to  be 
constructed  to  conform  to  different  user  views. 

C.  SJJRVET  PINPOINTS  DBMS  ADVANTAGES 

A  survey  conducted  by  Gabcielle  and  John  Wiorkowski  of 
27  different  computer  user  sites  utilizing  a  variety  of 
commercial  DBMSs  produced  the  results  shown  in  Figures  2,  3, 
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4,  ar.d  5.  f  24  ]  The  user  alias  involved  included 
representatives  of  industry,  government,  education  and 
research,  and  several  miscellaneous  others.  Seventeen  sites 
had  their  DBMS  installed  for  at  least  one  year.  The  other 
ten  were  newcomers.  The  advantages  and  disadvantages  of 
DBMSs  listed  in  Figures  2,  3,  4,  and  5  were  rated  on  a  scale 
of  1  to  5,  with  5  being  the  most  important  and  1  being  the 
least  important.  Several  important  conclusions  were  derived 
which  correspond  with  the  abovs  disc  us  si  nr.  about  3  E !'  3  3 : 

1.  Data  independence  was  rated  most  important.  "The 
users  stated  that  the  data  organization  is  trans¬ 
parent  to  the  programmers,  that  data  is  removed 
from  the  programs,  and  there  is  increased  ease  in 
programming  both  during  development  and  during 
maintenance  of  an  application  using  a  DBMS. 

"As  data  independence  increases,  maintenance 
.  costs  ana  costs  of  adding  applications  should  and 
do  increase.  Prospective  DBMS  users  can  indeed 
anticipate  a  decrease  in  these  costs."  [24;  109] 

2.  Data  Integrity:  "Several  users  commented  that  end 
users  really  look  at  the  data  now  as  compared  to 
the  application's  voluminous  reports  prior  to  DBMS. 

The  end  user  vilL  call  aboit  an  error  and  a  correc¬ 
tion  can  be  made  immediately."  [24:  113]  This 
immediate  correction  capability  is  possible  through 
data  centralization  in  a  D3MS  environment. 

3.  Two-thirds  of  the  users  surveyed  (18)  were  on-line. 

The  average  rating  of  these  18  users  as  to  the 
or.-line  benefits  was  4.4  (as  opposed  to  the  4.0 
average  rating  listed  in  Figure  2  which  includes 
the  9  users  who*were  not  on-line).  Referring  to 
Figure  2  it  can  be  seen  that  the  4.4  rating  of 
on-line  benefits  from  on-line  users  is  equal  to  the 
4.4  rating  given  to  the  most  important  benefit, 
data  independence.  Various  responses  by  the  users 
includ ed: being  on-line  is  the  most  important 
advantage  of  DBMS';  'on-line  contributes  greatly  to 
the  advantage  of  the  data  base  approach';  'ease  of 


45 


progra  aiming  on-line’;  etc."  [24:  110]  This  " 
ness"  in  the  ratings  is  logical  since  lata  in 
denes  (physical  and  logical)  is  required  to 
implement  on-line  interactive  query  capabilit 


close- 
d  s  c  e  r.  - 


ies. 


4.  &d  hoc  query  capability  to  handle  unanticipated 
requests  requires  on-line  capabilities.  Regarding 
the  handling  of  unanticipated  requests,  the  survey 
revealed  that  "the  online  users  had  a  significantly 
higher  increase  (3.2)  compared  to  the  off-line 
users*  increase  (1.4).  The  on-line  users  also 
believed  that  tie  information  received  from  the 
application  on  DBMS  was  considerably  more  useful 
(3.1)  to  end  users  in  their  daily  activities  than 
the  off-line  users  did  (1.4)."  [24:  110] 


"cte  the  decrease  in  data  redundancy 


—  3 


s  3. 


6.  One-third  of  the  users  responded  that  the  DBMS 

replaced  mere  than  one  application.  Additionally, 
other  users  stated  that  applications  files  had  been 
reduced  in  number  and  that  several  systems  that  had 
previously  bean  disjoint  were  integrated  in  the 
DBMS  environment. 


7.  Finally,  comparisons  of  Figures  2  and  3  with 

Figures  4  and  5  reveal  that  the  benefits  with  the 
lowest  ratings  ware  more  important  to  the  organiza¬ 
tion  than  the  highest  rated  disadvantages.  ?hQ 
conclusion  drawn  is  that  tie  advantages  far  cutway 
the  disadvantages,  and  that  the  disadvantages  are 
not  unmanageable. 
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Advantage 


Import  ance 


Data  Independence  4.4 

Dana  Integrity  >.3 

On-line  benefits  4.0 

Centralized  control  3. 3 

Ease  and  flexibility  in 

restructuring  and  aaintainiag  data  3.7 

Reduction  in  data  redundancy  3.6 

Integrated  vs.  independent  applications  3.  5 

Quick  handling  of  unanticipated  requests  3.5 

Programmers  not  having  to  know 

physical  structure  3.  5 

Security  and  Privacy  3.1 

Strangely,  the  data  oase  concept  is  sc  tightly  linked  with 

—  ’*  —  S  2  ^  t  ^  ^  S.3  “  33.^017 

advantage  of  DBMS. 


Hov  Users  Bate  the  Importance  of  DBMS  Advantages 
(oa  a  scale  of  1  to  5) 

Figure  2  ‘24:  110] 
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Advantage  realized 


Sain  or  (Seduction) 


Data  Independence  3.2 
Data  Integrity  2.5 
Centralized  control  2.3 
Ease  and  flexibility  in 

restructuring  and  maintaining  data  2.9 
Reduction  in  data  redundancy  (1.5) 
Integrated  vs.  independent  applications  2.3 
Quick  handling  of  unanticipated  reguests  2.0 
Programmers  not  having  to  know 

physical  structure  2.0 
Security  and  Privacy  1.2 


Other  change 


Maintenance  costs  (0.7) 
Cost  of  adding  applications  (1.7) 
Ability  to  backup  and  recover  2.2 
Number  of  characters  stored  0.8 
Timliness  of  information  2.6 
Osefulness  cf  information  2.5 


Some  changes  realized  with  the  installation  of  a  data  Base 
management  system  are  actually  not  directly  related  to  it. 
Many  users  claimed,  for  instance,  that  backup  and  recovery 
was  made  more  difficult  by  the  installation  of  a  DBMS;  the 
gain  in  recoverability  actually  came  from  their  being  forced 
into  developing  better  procedures  tc  make  the  DBMS  applica¬ 
tions  work. 


Degrees  of  Change  After  Installing  DBMS 
(oa  a  scale  of  1  to  5) 

Figure  3  [24:  110] 
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Disadvantage 


Import ance 


Operational  inefficiency  2.3 
Additional  operating  cost  -• 4 
Cost  of  additional  hac  dvace/software  2.3 
Additional  cost  of  storing  data  2.0 
End  user  problems  in  the  transition  2.2 
Cost  of  the  DBMS  2.  1 
Cost  of  installing  DB1  S  2.0 


including  higher  operating  costs,  were  usually  see 
important  than  the  advantages. 


How  Osers  Hate  tha  Iaportanca  of  DBHS  Disadvantages 
(on  a  scala  of  1  to  5) 

Figure  «  [2»:  113] 
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Disadvantage 


Increase 


Operational  inefficiency  1.1 
Additional  operating  c os z  1.4 
Cost  of  additional  hardware/software  1.1 
Additional  cost  of  storing  data  0.4 


Average  increases  in  major  costs  and  in  operational  ineffi¬ 
ciency  were  seen  as  "over  20X"  oy  the  installations  polled. 
The  low  number  seen  for  the  increase  in  data  storage  costs 
is  somewhat  deceiving  too,  since  many  users  extended  their 
applications  when  it  went  on  DB1S  and  saw  costs  go  up  by 
half. 


Degrees  of  Change  After  Installing  DBMS 
(on  a  seals  of  1  to  5) 

Figure  5  [24:  113] 
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THE  DATA  3A5E  &DMIN  I  STRAPS 


With  the  applications  approach  to  automation  the  canter 
of  attention  is  on  the  procedures  or  programs  upon  which 
data  files  are  constricted.  With  the  data  base  approach  the 
center  of  attention  is  on  the  lata  itself.  Since  the  value 
of  data  is  oroDcrt ion  a  1  to  the  accuracy  of  the  data,  and 
since  most  data  will  be  centalizei  with  the  data  base 
approach,  it  follows  that  centralized  definition  and  control 
of  an  organization's  physical  data  base  is  required  for  a 
successful  integrated  data  base  environment.  The  IRS  execu¬ 
tive  is  one  side  of  this  data  control  "coin."  fie  is  respon¬ 
sible  for  interpreting  organizational  policies,  goals,  and 
objectives.  The  IRS  function  is  strictly  aor.-tschr.ical  ^ 
nature . 

The  technical  side  of  the  data  control  "coin"  is  the 
Data  Base  Administrator  (DBA).  The  DBA  is  "a  human  function 
with  responsibility  for  the  definition,  organization, 
protection,  and  efficiency  of  tie  data  bases  in  the  data 
base  environment,  including  responsibility  for  defining  the 
rules  by  which  data  is  accessed  and  stored."  [25:  6]  The 
wide  range  of  specific  responsioilities  assumed  by  the  DBA 
are  listed  in  Figure  5.  These  responsibilities  of  the  DBA 
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DATA  BASE  DESI3N 


Content 

Creation 

Reconciling  differences 
Dictionary /Directory 
Create 
Maintain 

Data  compression 
Data  classi  ficatioa/ro ding 
Data  Integrity 
Backup 

Restart/r  eco  very 


DATA  BASE  OPE&ATI3  N 

DED  custodian/authority 
Maintain 
Add 
Purge 

Data  base  maintenance 
Integrity 

Detect  losses 
Repair  losses 
Recovery 

Access  for  testing 
Dumping 

Software  for  DED/DD 
Utility  programs 
Tables/indexes,  err.  for 
end  user 
Storaae 

Physical  record  structure 
Logical-physical  mapping 
Physical  storage  device 
assign  ments 
Security /access 
Assign  passwords 
Assign  lock/key 
Modifying  passwords/ke  ys 
Logg  ing 
Cryptography 
Hodificat  ion 


Retrieval 

Search  strategies 
Statistics 
Access 

frequency  of  processing 
Space  use 
User  utilization 
Response  time 

Design  operational  procedures 
Access  to  data  base 
Access  for  testing 
Interfaces 
Testing  system 


MONITORING 

Quality  of  data  validity 

Performance 

Efficiency 

Post 

Dse/utilization 

Security/privacy 

Audit 

Compliance 

Standards 

Procedures 


OTHER  FUNCTIONS 

Li ason/comaunications  with: 
End  users 

Analyst s/pr ogr aramers 
Training  on  data  base 
Consultant  on  file  desi 
Design  operational  proo 
Access  to  data  base 
Access  for  testing 
Interfaces 


Functions  of  a  Data  Base  Administrator 


Figure  6  [  26:  185] 
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are  interpreted  to  fall  into  flue  major  categories:  (U  D-.ta 
Definition  and  Data  Base  Design,  (2)  Administration, 

(3)  Operations,  (4)  system  Monitoring  and  Improvement,  and 
(5)  General  Support.  [25:  7] 

The  Data  Definition  and  Data  Base  Design  function  is 
shared  with  the -IBB  executive.  The  IRM  executive  ensures 
that  information  standards  and  policies  are  developed, 
disseminated,  and  enforced  and  that  data  to  be  stored  in  the 
data  base  is  compatible  with  the  information  standards  and 
policies  of  the  organization.  The  DBA  ensures  that  rules 
for  user  access  are  pr omuigtasd  and  enforced.  Integrity 
aspects  include  protection  of  the  data  base  against  inaccu¬ 
rate,  invalid,  or  missing  data,  and  security  aspects  include 
protection  of  the  data  base  fron  purposeful  and  illegal 
access,  destruction,  or  dislocation. 

The  Administration  function  of  tne  DBA  ensures  that  all 
the  "rules"  are  being  followed;  i.e.,  that  organizational, 
government,  and  other  pertinent  directives  and  policies 
regarding  the  disposition  of  the  organization's  data  are 
beinq  obeyed,  that  data  base  security  and  integrity  stan¬ 
dards  are  being  used  in  .oy-to-diy  operations,  and  that 
proper  documentation  of  the  data  base  environment  (such  as 
the  recording  of  procedures,  standards,  guidelines,  and  data 
base  descriptions)  is  being  conducted. 
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Under  t  ha  Operati  ons  function,  the  DBA  ensures  “hat  ell 
resource s  within  the  3 ata  base  environment  operate  in  an 
efficient  and  effective  manner.  Both  formal  and  documented 
procedures  for  user  access  to  tie  data  base  must  be  used, 
additionally,  scheduling  of  computer  time  to  ensure  priority 
use  of  the  data  base,  utilization  or  repair  of  data  base 
components,  and  general  operational  use  of  the  data  base 
must  be  performed.  Dther  important  components  of  the 
Operations  function  include  maintenance  of  the  DDS  and 
ensuring  that  system  recovery,  and  security  procedures  are 
properly  exercised  and  controlled. 

System  Monitoring  and  Improvement  ensures  an  efficient 
level  of  service  while  effectively  maintaining  data  bass 
integrity.  System  monitoring  procedures  measure  the 
performance  of  both  the  hardware  and  software  components  of 
the  data  base  environment.  The  DBA  is  responsible  for 
reviewing  the  results  of  monitoring  the  computer  system, 
identifying  difficulties  and  inefficient  areas  of  operation, 
and  initiating  any  activities  needed  to  improve  the  data 
base  environment.  Inis  activity  is  called  "tuning"  of  the 
data  base. 

The  final  function.  General  Support,  includes  the 
educating  of  new  user3  in  the  proper  operation  of  the  data 
base,  and  the  continuing  education  of  present  users  to 
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ensure  that  all  components  -ana  standards  of  the  lata  base 
environment  are  effectively  and  properly  being  used.  The 
DBA  is  also  the  point  of  contact  within  the  organization  who 
should  keep  abreast  of  outside  developments  relevant  to  the 
operation  and  administration  of  the  organization's  data 
base(s)  and  DBMS.  In  the  case  of  SNAP  systems,  the  ship¬ 
board  DBA  would  liason  with  the  principal  shore  activity 
responsible  for  the  direct  support  of  the  shipboard  comurer 
systems.  This  shore  activity  is  the  Navy  lanageaen4-  Systems 
Support  Office  (NAVMA5  SO) .  tinder  SNA?  many  functional  area 
applications  are  being  developed  by  NAVI1A550  that  are  stan¬ 
dardized  for  use  throughout  the  Fleet.  In  a  data  base  envi¬ 
ronment,  strict  controls  would  nave  to  be  implemented  with 
the  standardized  applications  so  that  shipboard  personnel 
could  r.ot  modify  the  applications  without  the  authority  of 
NAVMASSO.  The  DBA  is  the  central  personality  who  can  ensure 
that  use  of  standardized  applications  is  strictly  enforced, 
and  who  can  maintain  the  necessary  liason  with  NASVMASSO 
regarding  the  use  of  specialized  applications  as  well  as  the 
DBMS  itself. 

The  centralized  control  over  data  activity  (as  oppposed 
to  just  data)  encompassed  by  tha  DBA  function  will  result  in 
a  data  base  environment  that  is  more  error  free  than  the 
decentralized  environment  of  the  applications  approach. 
Additionally,  an  atmosphere  of  standardization  will  result 
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which  will  facilitate  the  minimization  of  data  redundancy 
and  simplify  the  sharing  of  callable  data  across  organiza¬ 
tional  lines.  However,  in  order  to  realize  these  benefits, 
the  DBA  must  take  on  a  wide  variety  of  responsibilities 
(Figure  6)  which  require  close  and  constant  attention. 
Therefore  the  DBA  should  be  a  primary,  full  time  assignment. 
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VI.  CON  lit,  as  IONS 


The  0. S.  Navy  is  in  a  constant  state  of  growth  in  order 
to  meet  its  goal  of  5D0  ships.  The  result  of  this  growth  is 
added  complexity  in  both  the  operating  and  managing  of 
ships.  Automation  with  computers  has  enabled  newer  ships 
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human  intervention,  resulting  in  reduced  manning  levels 
aboard  ships.  The  combination  of  increased  Fleet  activity 
and  reduced  ship  manning  levels  has  resulted  in  a  severe 
administrative  burden  upon  shipboard  personnel  which  signif¬ 
icantly  affects  ship  performance  and  personnel  morale'  and 
retention.  The  purpose  of  the  Shipboard  Mon-tactical  AD? 
Program  is  to  alleviate  much  of  this  administrative  burden 
through  the  employment  of  non-tactical  computers. 

The  first  requirement  in  developing  any  system  is  to 
define  the  objectives.  It  is  the  premise  of  this  paper  that 
the  objectives  of  SNA?  only  address  the  short  term  because 
the  intention  of  SNAP  is  to  satisfy  certain  pre-deterain ad 
functional  needs  of  the  Fleet;  and  to  compensate  for  the 
unfamiliarity  and  inexperience  of  shipboard  personnel  with 
the  procedures  required  to  maintain  a  DBMS  environment  in  a 
reliable  state.  The  result  is  an  applications  approach  to 
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SI! A?  system  development,  with  no  planning  or  dsveicp-ner  ' 
being  conducted  for  eventual  transition  no  a  datn  base  envi¬ 
ronment.  If  what  has  already  been  defined  is  all  that  will 
ever  be  required  of  the  SNAP  systems,  then  the  applications 
approach  sill  probably  be  better  than  the  data  base 
approach:  "It  is  quite  common  for  a  DBMS  to  be  used  to  solve 
a  particular  problem  with  the  intention  of  having  no  impact 
on  the  company.  However,  there  is  a  danger  that  using  a 
DBMS  in  this  way  can  result  in  its  use  increasing  ir.  an 
uncontrolled  way,  often  resulting  in  disasterous  conse¬ 
quences."  r 27:  SR/h  1  However,  the  administrative  environ¬ 
ment  in  the  Fleet  is  constantly  active  in  that  new 
requirements  are  created  and  already  established  require¬ 
ments  are  changed  or  updated.  Additionally,  familiarization 
with  the  SNAP  systems  will  er.coirage  their  use  beyond  the 
scope  of  the  pre-aefined  functional  needs. 

An  applications  approach  is  a  "brute  force"  method  for 
meeting  the  increased  information  requirements  in  the  Fleet. 
The  increased  capicty  to  process  data  will  be  realized;  but 
the  static  and  unchangeable  characteristics  of  the  applica¬ 
tions  environment  tend  to  make  data  inaccurate,  inconsis¬ 
tent,  or  outdated  because  data:  J5:  ID/21] 

•  Is  stored  in  different  formats. 

•  Is  often  not  shareable,  necessitating  redundant 

files. 
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»  Is  often  not  easily  recoverable  or  secure. 

•  Usually  has  structure  tiei  directly  to  program 

logic. 

The  result  will  be  tha  inability  to  generate  the  necessary 
information  for  the  on-going  success  of  tha  organization.  A 
move  from  processing  d  ata  with  an  applications  approach  to 
producing  information  with  a  data  base  approach  will  hav a  to 
be  made,  f  2  8:  ID/9] 

The  second  intention  of  SHAP  (compensation  for  lack  of 
knowledge  of  shipboard  personnel  in  AD?)  is  based  on  tech¬ 
nical  and  training  lii  itatior.s.  Figure  6  illustrates  a 
multitude  of  functions  to  be  performed  by  the  DBA,  the  most 
critical  of  which  ara:  (1)  backup  and  recovery,  (2)  privacy 
and  security,  (3)  concurrency  and  deadlock  control,  and  (3) 
auditing.  The  proper  operation  of  a  computer  system  depends 
on  the  affective  impalement at ion  of  these  functions  whether 
computer  system  development  follows  an  appliactions  approach 
or  a  data  base  approach.  "Tha  integrity  of  the  data  base 
may  be  affected  by  a  software,  a  hardware,  or  operator 
malfunction.  The  malfunction  may  be  of  a  magnitude  serious 
enough  to  either  completely  destroy  the  data  base  or  to 
leave  it  in  a  stata  that  its  contents  cannot  be  vouched  for. 
It  is  therefore  necessary  for  the  system  to  possess  the 
ability  to  recover  from  such  a  malfunction  while  maintaining 
the  completeness  (or  integrity)  of  the  information  held 
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within  the  data  base.’*  [29:  112]  Admittedly  these  functions 
are  mors  complex  in  a  data  base  environment  than  in  an 
applications  environment.  Howavar,  the  key  to  success  in 
either  environment  depends  not  upon  the  relative  complexity 
of  the  two  approaches,  but  rather  upon  the  proper  education, 
training,  and  management  discipline  used  by  personnel 
designated  to  implamant  aad  operate  the  systems. 

To  illustrate  that  tha  disadvantage  of  user  inexperi¬ 
ence  with  a  DBMS  is  a  short  tern  effect  which  can  be  over¬ 
come  using  sound  management  and  training  techniques, 
consider  a  representative  function  of  the  DBA  -  backup  and 
recovery.  Referring  to  Figure  3  in  chapter  IV.,  the  ability 
of  the  surveyed  organizations  to  backup  and  recover  as  a 
result  of  implementing  a  DBMS  increased  by  2.2  on  a  scale  of 
1  to  5.  As  the  figura  notes,  complications  with  backup  and 
recovery  were  initially  experienced  with  the  use  of  a  DBflS. 
However,  these  complications  wara  overcome  by  development  of 
better  procedures,  with  the  nat  affect  being  positive.  As  a 
supplement  to  this  observation  oy  the  Wiorkowskis,  Ian  B. 
McCririck  and  Robert  2.  Goldstain  surveyed  555  large 
computer  users  in  Canada  both  tha  public  and  private  sectors 
regarding  the  functions  of  tha  iata  administrator. 

Responses  were  recaivad  from  43?  (253)  of  the  sample,  and  71 
claimed  to  have  an  explicit  iata  administration  function. 

In  response  to  the  quastion  of  how  the  time  spent  on  each 
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dara  administrator  task  was  expected  to  be  different  :j: 
years  later,  "  th«  majority  of  ns  respondents  felt  t.iev 
would  be  spending  more  time  in  two  years  on  every  responsi¬ 
bility  on  the  list.  3 nly  one  item  got  the  votes  of  as  many 
as  10%  of  the  DAs  for  becoming  less  important  -  the  levelop- 
ment  of  backup,  recover,  and  restart  procedures.'*  [  30:  1  34  ] 
The  results  of  these  two  surveys  infer  that  once  sound 
procedures  and  standards  are  defined,  and  proper  training 
conducted,  technical  limitations  are  steadily  corrected, 
resulting  in  increased  performance. 

After  SNAP  implementation  is  complete,  usage  cf  the 
system  will  result  in  increased  experience  and  knowledge  in 
users  as  to  the  true  capabilities  of  the  systems. 

Increasing  requirements  upon  the  3IIA?  systems  will  be 
focused  beyond  the  pre -determin e d  functional  needs  into  the 
area  of  aiding  the  management  decision-making  process.  This 
means  that  certain  information  from  each  department  of  a 
ship  will  have  to  be  accessible  to  all  other  departments  sc 
that  the  "information  resource"  of  the  ship  can  provide 
maximum  benefit  to  total  ship  performance.  Access  to  a 
ship's  information  resource  will  have  to  be  timely  and  reli¬ 
able.  This  will  be  accomplished  by  on-line  capabilities  of 
the  computers,  including  high  level  query  languages. 
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The  dual  requirements  of  fulfilling  certain  functions! 
needs  now  and  decisio  a -male  ing  needs  in  the  future  cannot  be 
provided  for  by  a  traditional  file  management  system  because 
the  applications  approach  is  only  function- or iented.  The 
data  base  approach  will  evolve  because  it  can  fulfill  both 
types  of  needs.  This  is  because  the  data  base  approach  is 
oriented  to  the  common  denominator  of  the  two  types  of 
needs  -  the  data  itself. 

As  the  need  for  a  data  base  approach  becomes  more 
predominant,  the  administration  of  a  ship's  information  will 
require  the  use  of  Information  Resource  Management.  The 
best  technical  implementation  or  the  IRM  concept  is  a  Data 
Base  Management  System  because  ISM  and  D3M3  both  support  the 
same  philosophy:  centralization  and  standardization  of  both 
data  and  the  control  of  data. 

A  common  management  tool  will  be  needed  to  bridge  the 
gap  between  the  management  of  data  and  information,  and  the 
automation  of  data  and  generation  of  information.  This  tool 
is  the  Data  Dictionary  System.  The  concepts  underlying  both 
IRM  and  the  operation  of  a  DBMS  can  be  explicitly  documented 
and  implemented  with  the  aid  of  a  DDS.  The  comparability  of 
IRM,  DBMS,  and  DDS  is  summarize!  in  Figure  7. 

Finally,  management  positions  will  have  to  be  estab¬ 
lished  to  enforce  absolute  authority  in  the  definition  and 


52 


use  of  a  ship's  data.  These  billets  aboard  ship  will  be 


"IF. H  executive"  and  a  "DBAS  executive."  The  IBM  responsi¬ 
bilities  will  fail  upon  the  executive  officer,  and  the  DBMS 
responsibilities  will  be  carried  out  by  a  shipboard  Data 
Base  Administrator.  The  number  and  variety  of  functions  to 
be  performed  by  the  DBA  dictate  that  the  data  base 
administrator  function  will  have  to  be  a  primary  billet. 


Data  Resource 

S&sassnai  go§i 

To  build  and 
control  corporate 
data  resources. 


To  organize  models 
of  corporat  e 
information . 


To  improve  the 
accessibility  of 
corporate  informa¬ 
tion. 


To  increas  e  the 
longevity  of 
system  and  data 
resources,  to 
facilitate  their 
maintenance  and 
enhancement  and 
thus  to  protect 
the  corporation's 
investment  in 
them. 


To  improve  the 
accuracy  and 
consistency  of 
corporate  informa¬ 
tion. 


DBMS 

Function 

Management  of 
corporate  data 
resources. 


Physical  support 
for  relationships 
between  data  that 
is  meaningful  to 
the  corporation. 


Physical  support 
for  data  access, 
by  keys  and  inter- 
record  relatior.- 
s  hips . 


Separation  of 
logical  and  phys¬ 
ical  data  base 
views,  making 
a  pplication 
programs  indepen¬ 
dent  of  changes  in 
data  organization 
and  making  new 
a  pplications 
easier  to  imple- 
i  ent. 

Elimination  of 
data  redundancy 
through  systems- 
supported  lethods 
of  data  integra- 
t  ion. 


Data  Dictionary 
Function 

Management  of  the 
definitions  and 
documentation  for 
corporate  data 
resources. 

Support  for  docu¬ 
menting  the  types 
of  information 
within  corporate 
data  resources,  as 
well  as  the  system 
components  that 
support  them. 

Support  for  inves¬ 
tigating  the  types 
of  corporate 
information  avail¬ 
able,  as  well  as 
the  means  by  which 
they  are  supported. 

Provision  of  cools 
to  accurately 
asses  the  specific 
impact  of  data  and 
system  changes  and 
to  determine  what 
the  content  and 
extent  of  existing 
resources  are. 


Elimination  of  the 
artificial  segre¬ 
gation  between 
system  documenta¬ 
tion  and  system 
driving  defini¬ 
tions. 


Comparison  of  DBS S  and  Data  Dictionary  Functions, 
With  a  Conson  Classification  of 
Data  Basource  Management  Goals 

I  13:  p.  37] 
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Fig  are  7 


Data  Resource 
Management  Goal 

To  bring  coordina¬ 
tion  and  consis¬ 
tency  to  infor¬ 
mation  system 
implementat  ion 
efforts. 


To  improve  the 
productivity  of 
the  data  resources 
staff. 


To  protect  the 
data  resource. 


DBMS 
Fu net ioi 

Centralization  of 
data  definition. 


Provision  of 
programming  tools 
to  implement 
complex  applica¬ 
tion  problems, 

*  nils  isolacing 
systems  from  the 
impact  of  change. 

Support  for  access 
security  and  data 
base  integrity, 
backup  and 
r  eccvery. 


Figure  7  (cant.) 


Data  Dictionary 
Function 

Centralization  of 
definition  manage¬ 
ment  standards 
enforcement, 
naming  procedures, 
and  modification 
control. 

Provision  of 
programming  aids, 
such  as  ready  made 
data  definition 
and  trustworthy 
impact  assessment 
cools. 


Support  for 
protection  of  all 
definitions  on 
which  information 
systems  are  built. 
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RECOMMENDATIONS 


The  recommendations  cited  in  this  section  are  made  a  der 
the  assumption  that  SNAP  implementation  will  not  be 
employing  a  data  base  approach.  Since  it  is  predicted  that 
the  increased  knowledge  and  experience  on  part  of  the  end 
risers  of  the  S'’.'?  systems  will  ssr.erete  res  jiremer.ts  to 
utilize  the  SNAP  systems  for  more  diversified,  management- 
oriented  applications  in  support  of  the  decision-making 
process,  it  is  necessary  that  planning  begin  new  for  devel¬ 
opment  of  a  data  base  environment  for  non-tactical  ADP 
support  aboard  ships. 

A.  MANAGERIAL  RECOMMENDATIONS 

The  initial  step  in  developing  a  data  base  environment 
is  the  education  and  training  of  the  managers  whom  the 
computer  systems  will  affect;  i. e.  ,  the  officer  corps.  The 
data  base  approach  is  characterized  by  the  centralization  of 
data  and  its  control.  Commanding  Officers,  Executive 
Officers,  Department  deads,  and  Division  Officers  all 
receive  formal  classroom  training  before  reporting  to  their 
respective  billets.  Fundamentals  of  the  Information 
Resource  Management  concept  must  be  addressed  during  this 
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classrccn  training  of  shipboard  managers:  (1)  information  is 
a  resource  that  directly  affects  the  perforaar.ee  of  the  ship 
in  carrying  out  its  mission,  and  should  therefore  be  managed 
with  the  same  considerations  given  to  other  resources;  and 
(2)  the  data  required  to  generate  administrative  support 
information  is  coordinated  and  controlled  "at  the  top" 

(i.e.,  the  Executive  Dfficer)  rather  than  at  lower  levels  of 
management.  This  prevents  daca  from  becoming  proprietary  as 
well  as  enforcing  top  management  involvement  in  producing 
the  "team  effort"  required  to  ensure  successful  performance. 

The  seccnd  important  step  which  should  be  taken  now  is 
the  establishment  of  a  Data  Dictionary  System  for  the  appli¬ 
cations  presently  being  developed  and  implemented  under 
SNAP.  The  central  repository  of  fata  definitions,  controls, 
and  standards  contained  in  a  QD5  is  invaluable  to  the  proper 
management  aboard  ship.  The  DDS  theme  of  improving  the 
authenticity  of  information,  or  documentation,  about  an 
organization's  applications  systems  sets  the  stage  for 
implementing  the  ISM  concept  in  a  data  base  environment. 
Secondly,  a  DDS  provides  a  common  denominator  between  the 
ship  and  their  primary  shore-based  support  activity, 
NAVMASSO,  when  help  or  consultation  is  required  regarding 
SNAP  operations.  As  confidence  in  automation  increases  and 
a  data  base  environment  begins  to  evolve,  the  DDS  will  be 
the  primary  tool  used  for  systems  development. 


5  7 


Because  a  pass! v=  DCS  places  considerable  ieanr.c  far 
evert  and  e x;. -..nsive  D3A  involvement  ir.  many  system  sapper-: 
activities  in  order  to  ensure  the  dictionary's  viability  as 
an  accurate  system  aad  data  documentation  tool,  it  is  recom¬ 
mended  that  a  passive  dictionary  be  constructed  for  two 
reasons:  (1)  it  is  inherently  less  complex  than  an  active 

dictionary;  and  (2)  considering  that  many  applications  are 
being  devloped  centrally  for  use  throughout  the  fleet  on 
equipment  furnished  Dy  different  contractors,  the  port¬ 
ability  of  a  single,  centrally  developed  DDS  would  be 
enhanced.  It  is  most  likely  that  two  central  DDSs  would 
have  to  be  developed  if  they  were  active  because  "the 
strongest  potential  for  the  development  of  an  active  system, 
at  least  theoretically,  is  where  the  same  vendor  supplies 
all  components  cf  the  overall  data  management  complex, 
including  the  host  language  compilers,  the  DBMS  (and  its 
compilers)  and  the  DOS.  This,  of  course,  normally  means  the 
hardware  vendor."  [13:  42] 

The  third  managerial  recommendation  addresses  the  SNAP 
constraint  cf  nc  additional  personnel  being  required  to 
operate  the  SNAP  systems.  Aboard  ship,  this  constraint  will 
foster  assignments  to  data  management  and  operations  on  a 
collateral  duty  basis.  The  operation,  maintenance,  and 
control  of  a  data  processing  environment,  which  will  greatly 
impact  the  way  in  which  a  ship  does  business,  will  require 
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attention  tc  detail  and  follow- tarough  abilities.  Theae  <ey 
characteristics  of  effective  management  can  only  be  realized 
by  assignment  of  personnel  on  a  full  time  basis.  At  a 
minimum  the  person  in  overall  caarge  of  the  data  processing 
"department "  should  be  an  officer.  This  person  would  essen¬ 
tially  be  serving  as  the  ship's  Data  Base  Administrator  for 
the  ship's  non-tactical  ADP  support,  and  as  such  should  be 
given  the  status  of  a  department  head  accountable  to  the 
Executive  Officer. 8  given  than  personnel  experienced  (or 
ever,  educated)  in  data  processing  are  not  prevelar.t  enough 
to  fill  all  required  billets,  training  for  officers  in  data 
processing  will  have  t o  be  part  of  the  training  "pipeline" 
prior  to  reporting  aboard  a  ship.  Also,  a  pool  of  formally 
educated  officers  exist'who  have  completed  masters  degree 
level  education  at  tie  Naval  Postgraduate  School  in  Computer 
Systems  Management  (13  months)  and  Computer  Science 
(21  months)  . 

The  fulfilling  of  management  decision-making  needs 
encompasses  subordinate  functioaal  needs.  Therefore  a  data 
base  approach  is  a  more  sound  approach  to  realizing  both 
short-term  and  long-term  benefits  of  non-tactical  ADP 


•The  DBA  function  performed  by  the  individual  aboard 
ship  would  have  to  be  a  subset  of  a  centralized  Fleet  DBA 
function  (located  at  S AVMASSO)  because  the  initial  applica 
tions  are  standardized  for  implementation  throughout  the 
Fleet. 
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supper*.  As  such,  a  data  base  approach  should  be  instituted 
from  the  beginning  in  lieu  of  aa  applications  approach. 

Later  conversion  frou  an  applications  evvironment  tc  a  data 
base  environment  will  be  costly  and  disruptive:  "There  is  no 
doubt,  however,  that  providing  you  gather  the  necessary 
expertise  and  have  total  managei ent  commitment  that  the  path 
of  least  resistance  is  in  the  development  of  a  totally  new 
system."  [27;  SH/4]  Additionally,  a  DBMS  installed  under 
the  data  bass  approach  will  provide  the  ability  for  improved 
management  decisions  by  providing  faster  responses  to  unan¬ 
ticipated  requests  in  more  user-friendly  manner  than 
applications  systems. 

Thf  testing  of  a  DBMS  environment  should  be  performed 
prior  to  mass  implementation  in  the  Fleet.  The  establish¬ 
ment  of  prototype  systems  for  both  SNAP  I  and  SNA?  II,  pref¬ 
erably  at  NAVMASSO,  should  be  accomplished  to  facilitate 
systems  development  and  training.  A  DBMS  should  be  devel¬ 
oped  on  these  prototypes  so  first-hand  experience  of  the 
benefits  of  a  DBMS  can  be  experienced.  Standardized  proce¬ 
dures  and  training  methods  can  be  developed  in  crucial  func¬ 
tional  area  such  as  backup  and  recovery,  concurrency  con¬ 
trol,  privacy,  security,  monitoring,  auditing,  and  tuning. 

Finally,  plans  and  shipboard  test  platforms  should  be 
established  to  incr ene nf ally  implement  the  DBMS  environment 
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aboard  ship.  An  evolutionary  approach  to  implements-: ion  is 
necessary  to  preclude  an  atmospaere  of  ’’too  much  too  soon," 
where  users  not  accustomed  to  ADP  would  be  overwhelmed  with 
new  technology  and  procedures.  The  present  applications 
approach  that  is  being  used  for  SNAP  is  not  considered  to  be 
a  necessary  step  in  developing  a  DBMS  environment  because 
the  foundations  upon  which  the  applications  approach  is 
based  (function  oriented  and  decentralized)  are  not  compa¬ 
rable  with  the  the  foundations  of  the  data  bass  approach 
(data-oriented  and  centralized).  Therefore  systems  develop¬ 
ment  should  be  based  on  a  DBMS  from  the  start.  A  method  for 
incremental  implementation  of  SNAP  I  has  already  been 
presented:  f 3 1 :  4-3] 

The  initial  implementation  of  the  systems  would  be  a 
transaction-driven  aatch  system.  The  initial  implemen¬ 
tation  of  the  systems  would  offer  or.-line  inquiry,  but 
not  on-line  update.  All  updates  to  the  system  wcuid  be 
performed  in  a  batch  mode.  The  only  reduction  in  capa¬ 
bilities  would  be  the  deferral  of  the  on-line  update 
parts  of  the  system.  Accordingly,  all  requests  that 
require  updates  to  the  data  base  would  be  performed  in  a 
batch  only  mode.  Data  entry  would  initially  be 
performed  at  the  central  ADP  center.  Once  Remote 
Processing  Systems  (RPSs)  are  installed  at  other  loca¬ 
tions  in  the  ship,  data  entry  (still  for  batch  updates) 
could  be  gradually  shifted  to  those  locations  and  away 
from  the  central  ADP  center.  Since  on-line  update  is 
not  involved,  data  entry  wouli  not  adversely  effect  the 
response  of  IMMS-RT  and  SUADP5-RT.  By  performing 
updates  in  a  batch-only  mode,  the  problems  of  backup  and 
recovery  as  well  as  integrity  checking  procedures  are 
significantly  reduced.  The  systems  could  still  be 
supported  by  a  DBMS,  thus  providing  the  developers  and 
the  users  of  the  systems  with  all  of  the  DBMS  advantages 
outlined  above. 
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The  benefits  provided  by  an  incremental  approach  include  th 
following:  [31:  4-3] 

•  Ships  will  not  initially  reguire  a  fully  trained  DBA 
staff  aboard. 

•  Fewer  program  runs  will  be  required  to  maintain  the 
system  current  for  the  end-users. 

•  The  new  technology  will  be  introduced  to  the  ship¬ 
board  environment  in  an  evolutionary  manner. 

•  Upgraded  software  can  be  delivered  to  fleet  units 
earlier  than  fully  capable  applications  systems. 

•  Training  impacts  will  be  reduced. 

•  Developers,  users,  and  operators  will  "grow"  with 
the  new  systems,  just  as  is  done  in  industry,  albeit 
at  a  more  accelerated  rate  at  this  point  ir.  time. 

B.  FILE  AND  RECORD  STRUCTURING  USING  NORMALIZATION 

The  significant  managerial  considerations  of  IRK,  dds, 
and  DBA  presented  in  this  paper  are  important  for  efficient 
and  effective  use  of  A  DP  support  in  an  organization  regard¬ 
less  of  whether  an  applications  approach  or  a  data  base 
approach  is  used.  It  has  also  been  explained  that  the  data 
base  approach  using  a  DBMS  is  significantly  better  than  the 
applications  approach  in  supporting  these  managerial 
concepts.  However,  there  is  also  a  technical  aspect  of  ADP 
development  which  also  applies  to  both  the  applications 
approach  and  the  data  basa  approach,  which  is  also  more 
compatible  with  the  data  base  aooroach  than  with  the  appli¬ 
cations  approach,  and  which  can  be  viewed  as  the 
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fcur.dat  ion  for  the  aoove  managerial  concepts.  This  tech¬ 
nical  aspect  is  known  as  normalization  of  file  and  record 
structures.  Use  of  normalization  enables  file  and  record 
construction  to  be  accomplished  independently  from  program 
logic  and  storage  mechanics,  thus  resulting  in:  (1)  the 
simplest  possible  r epr esentatioi  of  data,  (2)  minimal  dupli¬ 
cation  of  data  values;  and  (3)  better  machine  performance 
(e.g.,  when  a  data  item  is  updated,  fewer  records  must  be 
read  and  written). 

One  operational  affect  upon  the  manager  is  the  preserva¬ 
tion  of  old  views  of  data  whea  new  associations  between  data 
items  are  added,  or  new  usage  patterns  occur.  Consequently, 
the  rewriting  of  programs  to  conform  to  new  associations  or 
usage  patterns  is  prevented.  Possible  disruptions  to  a 
program  would  occur  if,  for  instance,  new  associations  or 
usage  of  data  force  the  splitting  of  records  or  the  changing 
of  record  keys.  [20:  231  ] 

Disruption  of  usee  applications  can  also  be  the  causa  of 
one  or  more  anomalies  associated  with  faulty  file  and  record 
design.  Explanation  of  these  anomalies  can  best  be  under- 
stood  by  referring  to  a  simple  example  file  named  SUPPLIERS. 
SUPPLIERS  consists  of  the  following  fields: 
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I  I  1  i  I 

I  SNAME  |  3ADDRESS  1  ITEM  |  PRICE  | 

I  I  I  I  I 

The  first  anomaly  is  teduiiiHal*  The  name  and  address  of 
each  supplier  oust  be  repeated  for  each  item.  The  second 
anomaly,  update.  folLows  from  redundancy.  If  the  address  of 
a  supplier  were  to  change,  it  is  possible  that  it  will  be 
changed  in  cne  record  and  not  iu other.  Thus,  there  would 
not  be  a  unique  addrass  for  each  supplier  as  expected.  The 
other  two  anomalies  are  desertion  and  delation.  In  the 
SUPPLIERS  file  infornation  about  a  new  supplier  cannot  be 
entered  independently  of  the  item(s)  sold.  Conversely,  if  a 
supplier  only  appears  once  and  for  some  reason  the  corre¬ 
sponding  item  sold  is  no  longer  considered  relevant  to  a 
particular  application,  the  deletion  of  the  record  based  or. 
the  ITEM  value  will  also  delete  the  name  aod  address  infor¬ 
mation  about  that  supplier.  Referral  to  that  supplier  in 
the  future  regarding  a  different  item  would  not  be  possible. 
[32:  166-167] 

The  normalization  process  is  a  stepwise  process  which 
reduces  complex  file  and  record  structures  to  simpler  struc¬ 
tures  that  inherently  minimize  potential  disruptions  to  user 
applications.  Complex  structures  (those  which  contain 
repeating  fields  or  groups)  are  considered  non-normalized. 


From  the  initial  non-norma  lized  forms,  files  are  simpli-iel 
in  three  steps,  the  products  at  each  step  being  firsr , 
second,  and  third  noraal  fora  files,  respectively.  The 
third  normal  form  is  considered  optimum. 

Normalization  is  oased  on  tie  concept  of  functional 
dependency.  We  say  that  "item  3  of  data  record  D  is  func¬ 
tionally  dependent  on  item  A  of  D  if,  at  each  instant  of 
time,  each  value  of  A  has  no  more  than  one  value  of  B  asso¬ 
ciated  with  it  in  data  record  D.  In  other  words,  item  A  is 
said  to  identify  item  a."  [33:  117]  Symbolically, 

A  - >  B  is  read  "A  functionally  determines  3,"  or  "3  is 

functionally  determined  by  A."  Also,  A  — /-->  B  is  read  "A 
dees  not  functionally  determine  B,"  or  "B  is  not  function¬ 
ally  determined  by  A."  In  the  SUPPLIES S  file,  the  following 
is  true: 

5  NAN  E - >  5  ADDRESS 

SNANE  ITEM - >  PRICE 

I  TEN  —  /— >  SCJPPLIEH 
PRICE  — /~>  I  TEN 

The  first  normal  form  is  generated  by  removing  all 
repeating  fields  or  groups.  This  simplifies  the  file  struc¬ 
ture  by  shifting  the  logical  representation  of  relationships 
from  variable  length  records  to  fixed  length  records. 
Normalization  into  second  and  third  normal  forms  will  be 
demonstrated  using  the  following  file:  [33:  113] 
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file  Name:  ORDERS 

i  T  T  \  ’  T  T  \ 

| ORDER- ( PRODUCT- (CUSTOMER-!  CDS TOMER- | CREDIT- 1  QTY-  ( 

|  NR  |  KB  |NAME  (ADDRESS  |  RATING  (ORDERED! 

I _ I _ I _ I _ I _ I _ I 

ORDERS  is  already  in  first  normal  form  and  the  record  key  is 
the  concatenated  key  3RDER-NR  PRODUCT-NR.  Analysis  of  the 
ORDERS  file  yields  the  following  functional  dependencies: 

0  RDER-NR  PRODUCT  NR - >  QTY-OR  DE  RED 


ORDER-NR  - >  CUSTOMER-NAME 

ORDER-NR  - >  CUSTOMER- ADDRESS 

ORDER-NR  - >  CREDIT-RATING 


A  record  is  said  to  be  in  second  normal  fora  when  all  non- 
prime  attributes9  of  first  normal  form  files  are  fully 
dependent  on  the  record’s  entire  key  (including  concatenated 
keys).  In  the  above  record  structure  only  2TY-ORDERED  is 
functionally  dependent  on  the  entire  record  key  ORDER-NR 
PRODUCT-NR.  With  all  other  non-prime  attributes  the  item 
PRODUCT-NR  is  not  required  for  determining  their  functional 
dependence.  Therefore  this  structure  is  not  in  second 
normal  form.  Second  aorrnal  fora  files  can  be  created  by 
breaking  the  source  file  into  two  separate  files  as 
illustrated  below: 


9 A  non-prime  attribute  (field)  is  one  that  is  not  part 
of  the  record  key. 
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Fils  '.Tame:  ITEM-ORDERED 

T  T  T  T 

I  PRODUCT-NR  |  ORDER-NR  |  QTY-ORDERED  | 


File  Name:  WHO-ORDERED 

7  -  -  .  _ 

|  ORDER-NR  |  CUSTOMER-  |  CUSTOMER-  |  CREDIT-  | 

I  I  NAME  |  ADDRESS  |  RATING  i 

I _ I _ I _ I _ ! 

Third  normal  fora  files  are  attained  when  all  transitive 
dependencies10  are  removed  from  second  normal  form  files. 

In  the  file  WHO-ORDERED,  3 RDER-NR - >  CUSTOMER- NAME  is 

true.  However,  CUSTOM  ER-N  AME - >  CUSTOMER-ADDRESS  and 

CUSTOMER-NAME  - >  CREDIT-RATING  are  also  true. 

Therefore,  by  the  definition  of  transitive  dependency, 

ORDER-NR  - >  CUSTOMER-NAME  aid  ORDER-NR  - >  CREDIT- 

RATING  are  also  valid.  These  transitive  dependencies  can  be 
eliminated  by  forming  two  new  files.  These  third  normal 
form  files  are: 


*°Transitive  dependency  exists  when  one  or  more  nonprime 
attributes  (fields)  depend  on  the  record  key  only  via 
another  nonprime  attribute.  Assume  A  is  the  attribute  or 
set  of  attributes  making  up  a  record  key,  and  B  and  C  are 

nonprime  attributes.  If  A - >  B  and  B - >  C  are  true, 

then  A - >  C  is  also  true. 


« 
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Fils  Haas;  drdE? 


I  I  I 
|  38  DER-NR  J  CUSTOMER-  | 
I  1  SAME  | 
I _ I _ I 


File  Sane:  CUSTOMER 


I  I  II 

|  C0ST3ME8 -  |  CUSTOMER-  |  CREDIT-  | 

|  NAME  |  ADDRESS  1  SATING  | 

I _ I _ I _ I 


The  above  examples  show  how  simplicity  and  integrity  can 
be  built  in  to  file/rscord  design  through  normalization.  It 
can  also  be  seen  that  the  normalized  files  tend  to  take  on 
global  interpretations.  In  other  words,  these  files  are 
generalized  so  that  the  data  no  longer  applies  to  a  single 
application.  This  characteristic  makes  normalization  more 
compatible  with  the  lata  base  approach  than  with  the 
applications  approaca. 

Although  many  benefits  are  ierivable  from  normalization, 
something  is  lost  when  the  source  records  are  broken  up; 
namely  the  relationships  between  the  data  that  constituted 
the  source  records.  In  the  SUPPLIERS  fils,  normalization 
reguires  the  splitting  of  the  file  into  two  new  files,  one 
containing  SNAME  and  3ADDRESS,  an!  the  other  containing  ITEM 
and  PRICE.  However,  once  these  fields  are  separated  it  is 
not  possible  to  know  which  supplier  supplies  which  items. 
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With  the  applications  approach,  the  user  must  have  knowledge 
of  file  construction  in  order  to  develop  programs. 

Therefore,  the  physical  representations  are  synonimous  with 
the  logical  representations.  This  means  that  the  broken 
relationships  must  be  corrected  on  the  record  level.  A 
remedy  is  to  retain  the  key  of  the  source  record  (SNAME)  as 
the  key  of  the  new  file  containing  SNAME  and  SADDRESS;  and 
also  make  this  key  a  candidate  key11  of  the  new  file 
containing  ITS!?  and  ?3ICE,  the  result  being  a  new  file 
containing  SNAME  ITEM  PRICE  rather  than  just  ITEM  PRICE. 

Note  that  redundancy  of  SNAME  is  necessary  (in  the  file 
containing  SNAME  ITEM  PRICE)  in  order  to  correctly  normalize 
the  source  file. 

With  a  DBMS  such  compensation  does  not  have  to  be  accom¬ 
plished  at  the  record  level.  Through  the  Data  Definition 
Language  of  the  DBMS,  the  user  can  define  the  relationships 
between  the  normalized  files  in  a  high  level  language,  and 
the  DBMS  will  automatically  match  the  suppliers  in  the  one 
file  with  the  items  la  the  second  file.  This  removes  the 


llk  candidate  key  is  a  group  of  one  or  more  fields  that 
functionally  determines  a  record  occurance.  Additionally, 
all  of  the  fields  constituting  the  candidate  key  must  be 
required  to  functionally  determine  a  record  occurance;  i.e., 
given  a  group  of  fields  that  constitute  a  key  of  a  record 
occurance,  if  any  subset  of  that  key  can  also  functionally 
determine  that  record,  then  the  original  key  is  not  a 
candidate  key. 


* 
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As  evidenced  from  the  above  discussion,  continuity  of 
data  and  programmer  productivity  can  be  greatly  enhanced  by 
good  file/record  design;  and  goad  design  is  accomplished 
through  nor malization.  Therefore,  normalization  of  SNAP 
files  is  strongly  recommended  because  it  will  result  in 
simpler,  standardized  data  files,  and  it  will  contribute  to 
smoother  transition  co  a  data  base  environment  in  the 
future,  if  a  data  base  approach  is  not  used  initially. 
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